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1.0 INTRODUCTION 

The Control Data Distributed Communications Network (CDCNET or DCN for /">, 

short) (*) is an implementation of the Control Data Network Architecture V> 

(CDNA) . CDNA is a layered architecture based upon ISO's Open Systems 

Interconnection (OSI) reference model. An overview of both thetOSI model 

and CDNA appears in the CDNA General Design Specification (ARH4243) ; a 

condensed version of that overview will be supplied here in a future 

update. It will only be noted here that the standardization efforts on 

the OSI model and on the supporting protocols are not yet complete; CDNA, 

and therefore the DCN implementation, currently lead ISO standardization 

efforts in some areas. CDNA will track standardization efforts as they 

progress and CDNA implementations, such as DCN, will be upgraded 

according to marketing and customer requirements. 

This document describes the Distributed Communication Network (DCN) 
hardware and software as they will appear in the first release. 
Release 1 supports interconnection of C170 mainframes running C170 NOS 
and Network Products; asynchronous terminal support via the DCN is also 
provided. 

DCN hardware is known collectively as the Device Interface (DI) . DCN 
software that runs on the DI is known as the Distributed Communications 
Network Software (DCNS) . DCNS is concerned with moving data across the 
network and managing the network. 

Release 1 also includes a set of C170-resident software that is concerned 

Owith the definition and analysis of the DCN, as well as providing mass ^»Y 
storage and host console access for DCNS. \y 

This document is primarily intended to collect in a single place all 
information related to the external design of the DCN; this measure will 
facilitate a review of the overall DCN design and should also serve to 
identify design holes in external interface definitions. This document 
is also intended to provide input to the Publications and Graphics 
Division for use in preparing customer documentation. 



(*) This product family has been recently renamed so there is still 
documentation in existence that refers to the DCN by its former name, ACN. 
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1.1 INITIAL GLOSSARY 

An understanding of most large computer -related efforts involve learning a new 
vocabulary consisting largely of acronyms, and the Distributed Communications 
Network (DCN) is no exception. In general, new terms and acronyms will be 
defined in context in individual sections; however, an initial glossary is 
provided to give the reader at least a running start. 



O 



Network Solution 



Catenet 



Network 
CDNA 



DCN 



I; 

v. y 



DI 



DCNS 



A term used to describe a single instance of a 
communications medium; e.g. an Ethernet cable is a 
"network solution;" so is an X.25 Public Data Network. 

A term used to describe a group of multiple interconnected 
"network solutions" and systems, which collectively form a 
"concatenated network." 

A context-dependent term that may mean either "network 
solution" or "catenet." 

Control Data Network Architecture - the definition of the 
network architecture to which future Control Data 
communications products are to adhere. The term "network" 
in this context is really a catenet. 

Distributed Communications Network - The name of the first 
product implementation of CDNA; DCN includes both hardware 
and software. The term "network" in this context is 
really a catenet. 

Device Interface - the name of the hardware used in the 
DCN product. 

Distributed Communications Network Software - the name of 
the software used in the DCN product. DCNS runs in the 
DI. The term "network" in this context is really a 
catenet. 
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1.2 DOCUMENT ORGANIZATION ^-^ 

The remainder of Section 1 briefly describes the organization/content of this V^ 
ERS and provides a list of references for further reading. 

Section 2.0 of this ERS provides an overview of the hardware used to implement 
the DCN. The hardware is known oenerically as the Device Interface <DI) . The 
basic DI can be configured into a number of variants serving specific purposes 
within the DCN, e.g., Mainframe Device Interface (MDI) , Terminal Device 
Interface (TDI) , Network Device Interface (NDI) , and others to be defined for 
subsequent releases. 

Section 3.0 describes the major components of the DCN Software, aka DCNS. 
DCNS operates in the DI hardware and is composed of the following major 
elements : 

System Management Software - responsible for creation and 
maintenance of the system environment for the other 
functions. Creation of the system environment is provided 
by the Network Load & Startup software, which is 
responsible for dumping/loading/reloading the DI hardware 
as needed and for putting the network into an operational 
state. Other system management software provides the 
environment during normal operation of the network. 

Layer Software - responsible for transmission of data for 
!•"> the end-users of the DCN. •*>, 

Network Management Software - responsible for providing 
network management functions. 

The DCN software provides for the following three major external interfaces: 

C170 Interface 

X.25 Interface 

Terminal Interface 

An overview of each of the major interface components is given in last three 
subsections of Section 3; each is described in more detail in Sections 4.0, 
5.0, and 6.0, respectively. 
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1.2 DOCUMENT ORGANIZATION (continued) 

The remaining sections of this ERS, summarized below, describe various |^J, 

aspects of DCN; additional introductory remarks will be added as drafts 
of the remaining sections become available. - 

Section 7.0 describes the process of network validation; 

Section 8.0 defines Titles and Addresses; 

Section 9.0 describes the process of defining/configuring a 
DCN; 

Section 10.0 describes the operation of a DCN, primarily from 
the Network Operator's perspective; 

Section 11.0 describes failure management; in what manner can 
the network fail and what actions are taken to 
lessen/eliminate the impact of failure; 

Section 12.0 describes the accounting facilities provided for 

the DCN; 

Section 13.0 describes analysis and tuning of the DCN. This 
section also provides a description of the facilities provided 
to handle dumps. 

Section 14.0 describes DCN performance expected under various <y 
loads. 

Section 15.0 defines finite state machines. 

ERS appendices include: 

a summary list of all commands 

a summary list of all log messages 

file conventions and formats 

utilities 

scenarios; e.g., typical installation process, typical log-in 
process, etc. 

network initialization flow 



^w*"™ 
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1.3 REFERENCES 

1.3.1 Product References 

Additional information on the DCN product family as a whole may* be found in 
the following documents: 



Network Architectural Objectives 

ACN Design Requirements 

CDNA General Design Specifications 

Device Interface GDS 

C170/CDNA Interface Specification 

ACN Maintenance Software ERS 



ARH5011 

ARH5123 

ARH4243 

ARH4948 

S4234 

ARH5176 



o 



1.3.2 Hardware References 

Additional hardware information may be obtained from the following documents: 



DI Equipment Specification 
CIM Equipment Specification 
MCI Equipment Specification 
RS449 Equipment Specification 
RS232 Equipment Specification 
ESCI Equipment Specification 
PMM Equipment Specification 
SMM Equipment Specification 
MC68000 16-bit Microprocessor 



53984774 
67328072 
67328070 
67328074 
67328073 
67328071 
67328069 
21935466 
User Manual 



^U><^ 
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1.3.3 Software References 



o 



DCNS can be logically divided into the major component groups listed 
below, each of which is discussed in its own subsection. A bibliography 
of existing documentation for each component group is provided below 
under the component group heading. t 



o 



/r\ 



SYSTEM MANAGEMENT SOFTWARE 



PI Load & Startup Software 



System Ancestor ERS 
IDS 




ARH5377 J 

(*) ; 


Initial Loader ERS 




ARH5377 J 


Main/Initialization Bootstrap 


ERS 

IDS 


ARH5377 I 
(*) i 


Software Load Process ERS 




ARH5377 ! 


Configuration Procurer ERS 




ARH5377 I 


On-line Loader ERS 




(*) ; 


Initialization M-E ERS 




ARH5377 I 



Operational 



Software 



~r + 



Executive ERS 
IDS 

Common Subroutines Handbook 



ARH4976 
ARH5704 

(*) 



v...^ 



( 






*) Not submitted to DCS; no number available. 



(*) 
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1.3.3 Software References (continued) 



LAYER SOFTWARE 



c 



■% 



Lower Layers 




• Generic 3A ERS 


(*) • 


! Ethernet/Firmware/SSR ERS 


(*) • 


! HDLC SSR ERS 


(*) • 


! CIM Controlware ERS 


(*) ; 


I Device Manager (DVM) ERS 


(*) ; 



o 



Middle Layers 
Internet (Xerox) ERS 
Transport Generic Xerox ERS 



h — jirrmrrrmr + 

(*) 

(*) 



d 



Higher Layers 




(*) Not submitted to DCS; no number available. 
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1.3.3 Software References (continued) 



NETWORK MANAGEMENT FUNCTIONS 



o 



r 



\ Routing M-E ERS 


(*) • 


I Directory M-E ERS 
: IDS 


(*) ! 
(*) J 


! Dependent Log M-E (LSA) ERS 


(*) ! 


• Independent Log M-E ERS 


(*) 


! Error/Echo M-E ERS 


ARH6065 


• File Access M-E ERS 

• IDS 


ARH5960 
(*) 


! Dependent Command M-E ERS 


ARH5451 


! Independent Gontnand M-E (OSA) ERS 


(*) 


I Status Command Processor DAP 

J ERS 


ARH6014 
(*) 


I Statistics Command Processor/M-E 
• DAP 
j ERS 


(*) 
(*) 


• Initialization M-E ERS 


ARH5377 



v> 



'I 



if * 

J 



{*) Not submitted to DCS; no number available. 
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1.3.3 Software References (continued) 



C170 INTERFACE 



MDI -resident software 



C170 Support Software DAP 
C170 Gateway ERS 
BIP ERS 
MFI SVM ERS 
K-Display Support ERS 



(*) 

(*) 
ARH5378 

ARH5376 
ARH5968 






C170-resident software 



O 



C170/CDNA Console Access 




Helper Application 


S4406 


DCN Operator Facility GID 


S4500 


DCN File Utility GID 


S4566 


DCN File Server Application 

ERS 


S4507 


GID 


(*) 


DCN Log Server Application DAP 

ERS 


(*) 
(*) 



^lll^jp 



o 



{*) Not submitted to DCS; no number available. 
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1.3.3 Software References (continued) 



X.25 INTERFACE 



o 



! X.25 Support Layer ERS 


ARH5678 I 


• X.25 Packet Level ERS 


(*) ; 


1 X.25 Gateway ERS 


(*) • 






y 



TERMINAL INTERFACE 



I DCN Terminal Support DAP 


ARH5627 ! 


J LCM/TDSM ERS 


(*) \ 


! Asynch TIP ERS 


(*) I 



..y 



O 



(*) Not submitted to DCS; no number available. 
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2.0 PI HARDWARE OVERVIEW 

""% The Device Interface (DI) is a highly modular, microprocessor-based j^\ 

~? device. DI architecture is based on a multi-master bus and shared \^J 

resources. 

i 

The basic DI is diagrammed below and consists of: 

One Master Processor Board (MPB) 

An Internal System Bus (ISB) that can connect up to eight cards, 
one of which is the MFB 

Room for up to eight Line Interface Modules (LIMs) . 

Power supplies, cabinetry and cooling facilities 

+ + 

!HPB! 

+ ++ — / 

: T h e I S B 

+ -/ 



o 
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2.0 PI HARDWARE OVERVIEW (continued) 

,-. Because of the modularity of both the hardware and software, a DI can be 
i I configured to support a wide variety of functionality. For the first ay 

\S release, the following DI variants have been defined and named according w 

to their function: 

MDI Mainframe Device Interface, which connects the DCN to a 
C170 mainframe. The source or destination of the data 
transferred to/from the C170 is dependent upon other 
modules configured within the MDI. 

NDI Network Device Interface, which acts as a packet switcher 

to transfer data between network solutions. Depending upon 
the modules configured, a particular NDI may interface to 
any or all of the following: 

Public Data Network (PDN) - X.25 Type 
Local Area Network (IAN) - Ethernet 
Communications Line(s) - Point-to-Point Links 

TDI Terminal Device Interface, which is used to interface 

terminal devices to the DCN. Future releases may allow a 
TDI to interface to high-speed line(s) and/or a public data 
network to function as a "remote concentrator". 



v..y v - y 
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2.0 DI HARDWARE OVERVIEW (continued) 



'A 



The DI variants are created by configuring the appropriate combination of 
cards from the list below. These cards are known as "peripheral cards;" \^j) 
peripheral cards that contain microprocessors are known as "intelligent 
peripherals." t 

Mainframe Channel Interface (MCI) 
Ethernet Serial Channel Interface (ESCI) 
Communications Interface Module (CIM) 
Private Memory Module (Ff*l) 
System Main Memory (SMM) 

The MPB provides the main processing power for the DI. The MPB is 
shielded from most of the real-time external interrupts to allow parallel 
processing and high performance; for example, the CIM card handles all 
interrupts from communication lines, while the ESCI card handles all 
interrupts from Ethernet. The MPB is therefore free to process the next 
(or previous) message while the peripheral cards are busy transmitting 
the previous (or receiving the next) message. 

Normally, all cards share access to the system bus and to other system 
resources (e.g. SMM) . However, the MPB can selectively prevent one or 
more cards from accessing the bus, thereby allowing isolation of a bad 
card from the rest of the DI without physically removing the card from 
the DI. 

© Each card in the DI has a certain amount of Read Only Memory (ROM) ; the fl 
ROM is used to keep card identification (e.g. version number) and V^ 

self-test (on-board diagnostics) code. In addition, ROM on some cards 
contains boot code to facilitate loading of the DI across that specific 
card. All ROMs include a 16-bit checksum to facilitate detection of 
memory failures. 

All memories and data paths in the DI have a certain amount of built-in 
error detection capability. The system main memory (SMM) contains logic 
for single bit error correction/double bit error detection (SECDED) . All 
Random Access Memory (RAM) on individual cards contains a parity bit for 
each byte; parity is checked on all read operations. The data bus 
portions of the system bus, 68000 extension bus, and the LIM bus contain 
one parity bit for every eight bits of data. 



o 
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2.1 INTERNAL SYSTEM BUS 

,r~^ The Internal System Bus (ISB) is used for all communications between 

{ f different cards; the ISB consists of the following two parts: |J 

Interna l Transfer Bus (ITB) - The ITS is used for data transfer between 

individual cards as well as for the bus contention managements. It 

consists of a 24-bit address bus and a 16-bit data bus. It supports 
a 16-megabyte address range and a minimum transfer rate of 2.5 
megawords-per-second across the bus; each word contains 16 bits. 

The ITB is a multi-master bus in the sense that it may be owned by 
any one of the eight cards at a given point in time. The contention 
logic ensures that all cards have an equal opportunity to gain access 
to the ITB. 

Internal Control Bus (ICB) -The Internal Control Bus (ICB) is owned by 
the MPB and is used for control activities such as status and 
interrupts. The ICB contains an 8-bit data bus and a 4-bit address 
bus. 

The address bus allows the selection of up to sixteen cards, even 
though only eight cards are supported at present. 

The data bus allows the MPB to send a command byte to a selected card 
as well as to receive (read) a Status byte from a selected card. 
Each data bus access can be qualified in four different ways to 
facilitate support of up to four command and four status bytes. One 
f^'"\ of the command bytes is used to enable/disable access to the ITB from ^ x 

*v y a specific card. ^^ 

The ICB is also used to reset a card from the MPB. 
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2.2 INTERRUPTS 

t\ The MPB can send two types of interrupt to an intelligent card (e.g. CIM, g^ 

J ESCI) . One type of interrupt is non-maskable and is used for re-starting fy 

the card; the second type of interrupt is maskable. Both types are 
invoked by sending a command byte to the card via the ICB bus. ( 

All cards (intelligent or otherwise) can send an interrupt to the MPB 
card. These interrupts are scanned by the MPB in the following way: 

The MPB maintains a hardware counter which increments from to 
7 (for an 8-card backpanel) or from to 15 (for a 16-card 
backpanel) . 

Every time this counter is incremented, the card whose slot 
number equals the current value of the counter is checked for 
an outstanding interrupt. 

If one is present, the hardware stops incrementing the counter 
and initiates interrupt processing. At the end of the 
interrupt processing, the hardware continues incrementing the 
counter. 
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2.3 DI ADDRESS STRUCTURE 

The DI address structure provides a 16M-byte address space. The lower 256K of 
I this address space is local to each card in the sense that it is used for the 
S on-card memory as well as for addressing the local devices. This address 

space is not accessible via the ISB. 



O 



$000000 



$03FFFF 
$040000 



$0FFFFF 
$100000 



$FFPCFF 
$FFFD00 



$FFFFFF 



LOCAL ADDRESS SPACE 
(LOCAL TO EACH CARD) 



NON-SMM CARD SLOTS 
ADDRESS SPACE 



SMM CARD SLOTS 
ADDRESS SPACE 



OPTIONAL TRAPS AND VECTORS 
ADDRESS SPACE 



256K bytes 



768K bytes 



15359232 
bytes 



768K bytes 



Address space from $040000 to $0FFFFF makes up twelve 64K-byte segments. This 
address space is called the non-SMM card slots address space and is used to 
allow direct access from the MPB to peripheral devices (e.g. DMA chip) on 
other cards. Each 64K-byte segment will be associated with a specific card 
slot during installation. Note that, at present, only MCI card allows this 
type of access. 

The address space from $100000 to $FFFD00 is reserved for the SMM cards. This 
address space is accessible via the ISB to all cards connected to the ISB. 

The 768K bytes at the top of the address space are reserved for the interrupt 
and trap vectors for the cards and devices that require these vectors to 
reside at high addresses. 
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2.4 MAIN PROCESSOR BOARD 

The MPB provides the primary processing power for the DI software. It 
includes one Motorola 10-MHZ 68000 microprocessor, 16K bytes of RAM and 
16K bytes of ROM. 4K bytes of the RAM are battery-backed. The. MPB also 
contains a 68000 extension bus, which allows the MPB to access tip to 128K 
bytes of RAM on a Private Memory Module (PMM) card. The MPB's on-board 
RAM, as well as EMM memory, is provided to support fast memory access. 
Read and write operations to these memories occur with no 68000 "wait 
states". In addition, the MPB's on-board RAM can be dynamically 
write-protected via I/O instruction; however, the write protection is 
valid only if the 68000 microprocessor is in the user state. 

The MPB contains a 32-MHZ oscillator, which is used to provide a 16-MHZ 
clock for the ISB. The MPB also contains a real-time clock and calendar, 
which are battery-backed. The MPB also contains a Serial Communications 
Controller (SCC) device, which provides two RS232 ports; the baud rate 
for these ports is programmable between 300 and 9600 baud. 

The MPB includes a deadman timer which needs to be reset within nine 
seconds by software writing to a specific address ($00610A) . If a 
deadman time out occurs, halt and reset signals are sent to the 68000 
processor, which results in a DI reset. 

The MPB contains a software-readable 16-bit status register, illustrated 
below. 
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BITS 



BITS 









BIT 

: 8 : 

I I I 



BITS 



15 









contain information 
about the last bus error. 



indicates if the local RAM is 
write-protected or not. 



'%, 



Q 



indicates reason for the last reset 
signal to the 68000 processor. 



indicate environmental status 
such as battery low, 
temperature warning, 
temperature shut down, and 
AC power low. 
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2.5 MAIN PROCESSOR BOARD (continued) 

The MPB supports an "interrupt vector table" in memory locations $00000 
to $0003FF, which points to interrupt handler routines. The interrupt 
vector table resides in the MPB ROM, following a power-on or manual 
reset; the interrupt handler routines to which it points are rudimentary 
and contain only the code needed during DI loading. During normal 
network operation, the interrupt handler routines need additional 
sophistication. The MPB therefore contains logic to support alteration 
of the interrupt vector table. An I/O instruction is provided to 
interchange ROM with RAM; specifically, RAM locations ($008000 to 
$00BFFF) are interchanged with ROM locations ($00000 to $003FFF) . This 
allows dynamic changes to the interrupt vector table by re-writing the 
appropriate RAM location. 

The 68000 microprocessor supports seven interrupt levels, which are used 
on the MPB board in the following way: 

Level 7 The level 7 interrupt is generated as a result of the 
following two conditions: 

AC low (power failure) indication 

Temperature shut down (overheated) 

Software is expected to read the MPB status register 
to determine which of above two conditions is 
responsible for the interrupt. 

Level 6 The level 6 interrupt is generated by the SCC device 

Level 5 The level 5 interrupt is generated by the 68000 
extension bus. 

Level 4 The level 4 interrupt results from the scanned ISB 
interrupts and therefore can be from any one of the 
other cards. 

Level 3 The level 3 interrupt is generated by a device called 
CIO. This device is responsible for monitoring the 
various external switches on the MPB board. 

Level 2 The level 2 interrupt is generated by the Real Time 
Clock (RTC). 

Level 1 The level 1 interrupt is, at present, not used. 
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2.4 MAIN PROCESSOR BOARD (continued) 

The MPB 68000 microprocessor hardware provides a set of commands to the 
software to function the MPB hardware. These commands are executed by reading 
from/writing to address $0061XX, where the value of XX depends upon the 
specific command to be executed. The following is a list of these commands, 
which are described in detail in the MPB Engineering Specification: 

Read MPB status register 

Set and clear RAM write protect 

Set bus lock 

Read bus error address register 

Set and clear diagnostics mode 

Reset deadman timer 

Set and clear swap of ROM and RAM 

Set external indicators 

Read ITS loop back data 
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2.5 COMMUNICATIONS INTERFACE MODULE (CIM) 

~> The CIM is the controller for up to eight (8) Line Interface^ Modules (LIM) . 

I Each CIM contains a 10-MHZ MC68000 16-bit microprocessor with a minimum of 16K A \ 
*"* bytes of RAM with byte parity and zero wait state operation. A minimum of 8K v-r 

bytes of ROM with checksum is included for on-board diagnostics and 
initialization code. 

The cm has two interfaces: 

the LIM Bus interface to cormiunicate with the LIMs 

- the ISB interface to communicate with the rest of the DI 

The LIM Bus is an 8-bit data bus that can connect the Cm to a maximum of 
eight LIMs. LIMs are numbered according to their physical position in the LIM 
backpanel; the LIM closest to the outside is LIM 7. 

A "daisy chain" method is used to determine the specific source of an 
interrupt on the LIM Bus. The lowest numbered LIM has the highest priority. 
The CIM contains gating to bypass each LIM and substantially reduce the amount 
of time Squired for the disable signal to ripple thorugh successive LIMs. 
The bypass scheme on the CIM also allows for an empty slot in the middle of 
the daisy chain, which allows LIMs to be removed without the need to 
reconfigure the system's interrupts. 

The LIM Bus is protected with a single parity bit. Occurrence of a parity 
error causes a bus error . 

I/O control logic on the CIM generates properly timed control signals required v 
by the CIO and the peripheral chips on the LIM. It also generates the 
necessary handshake signals that are used by the processor control circuitry. 

The cm drives the LIM Bus using information provided by the MPB. 

The ICB is used for receiving commands from the MPB and to allow the MPB to 
read Srdware and software status.from the CIM Tne ™ «™£«" wlth «* 
SMM over the ITB. The MPB communicates with the CM over the ICB. 

Parity bits (upper and lower) are generated for all write operations 
regardless of the destination of the data, and without regard to byte or word 
operations. Parity bits may or may not be used depending on the destination 
o?5e data. Parity is checked, on a byte-basis, during read operations from 
the ITB, the LIM Bus, and the CIM RAM. 
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2.6 ETHERNET SERIAL CHANNEL INTERFACE (ESCI) 

The ESCI transports data between SMM and one Ethernet 10 Mbit Serial Channel. 
The ESCI card contains: 

Intel 82586 Ethernet Controller chip (the Controller)-' 

Intel 82501 Serial Interface chip 

Motorola MC68000 microprocessor (the Processor) 

16K bytes of RAM 

16K bytes of ROM 

The on-board ROMs contain initialization bootstrap code, diagnostics, and 
checksum. 

The Controller has priority access to both local memory and SMM. Extra 
on-card bus buffering is used to permit the Processor to access local memory 
while the Controller accesses SMM. 

The ESCI is connected to the Ethernet cable transceiver and to the DI's 
Internal System Bus (ISB) . Communication with the DI is primarily through 
data structures in SMM. 

Three kinds of Ethernet data loopback are available for use by diagnostics: 

local loopback on the Ethernet controller 

intermediate loopback on the Intel 82501 Ethernet Serial Interface 

external loopback on the Ethernet cable 

Because Motorola and Intel differ in their handling of memory stacks, the 
Processor and Controller store data differently on byte and 24-bit long-word 
operations; 16-bit operations are handled in the same manner. 

On byte operations, the Controller stores/loads the first byte in/from 
bits 0-7 when starting on an even address; the Processor stores/loads 
the first byte in/from bits 8-15 under the same conditions. Transfers 
between the Controller and the ITB mask this difference by swapping the 
two bytes across this interface; ITB bits 0-7 ■ controller bits 8-15 and 
bits 8-15 = controller bits 0-7 on all direct transfers between the 
Controller and ITB devices. Byte-swapping does not occur on transfers 
to local memory or between the Processor and the Controller. 

On long-word operations, the Processor stores/loads the two most 
significant bytes in/from the first location and the two least 
significant bytes in/from the following location; the Controller 
stores/loads the two least significant bytes in/from the first location 
and the two most significant bytes in/from the next location. If only 

Oreceive-data and transmit-data is transferred directly between the ITB ^,^ 
and the Controller, the byte-swap performed by this interface resolves * 1 
any addressing conflicts. Addressing conflicts between the Processsor V-a 
and the Controller must be resolved by on-board software. 
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2.7 MAINFRAME CHANNEL INTERFACE (MCI) 

s -^ The MCI, which operates under MPB control, will transport data between a C170 

I 12-bit channel and SMM. A chained DMA capability and on-board ROM containing || 
^ bootstrap code, diagnostics and checksum is provided, Two data packing and 

unpacking modes will be supported with channel and bus parity, bit and byte. 

Only one MCI per channel will be supported. Bass-on/pass-back wi?ll not be 

supported. Up to three MCI' s per MDI will be supported. 
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2.8 PRIVATE MEMORY MODULE (PMM) 

The PMM provides additional zero-wait-state RAM for use by the MPB via the 
j 68000 extension bus. Use of the PMM reduces the number of instruction 

accesses across the ISB and increases throughput of the MPB. The FMM can be 
configured in any of the DI variants. ;- 

The PMM contains either a 64K-byte memory or a 128K-byte memory; both have the 
same artwork and differ in the number of memory chips assembled. The smaller 
PMM is not field-upgradable. 

Maximum transfer rate for a read cycle is 140 nanoseconds. Since the memory 
is static, there is no constraint on minimum transfer rate. 

Maximum transfer rate for a write cycle is 180 nanoseconds. 

If a data parity error occurs on a write operation, the PMM sends a bus error 
signal; however, the incorrect data is written into the memory. 
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2.9 SYSTEM MAIN MEMORY (SMM) 

The SMM has a minimum of 512K bytes of RAM with internal refresh, Single Error 

> Correction/Double Error Detection (SEC/DED) , and error reporting to the MFB. | J 

* A diagnostic mode on the SEC/DED chip and programmable start address are also ^* 

features. 

ITB interface parity errors, SEC/DED multiple errors, and (if enabled) SEC/DED 
single bit errors are recorded on the SMM error log. The error log is a 
16-bit register that contains information about the type and location of 
error (s) . When an error is recorded in the error log, an KB interrupt is 
generated and the log is locked. The error log logs only one error at a time; 
new errors can be recorded only after the log is unlocked by a Master Clear, 
Reset, or by reading the log. The error log is read by an ITB diagnostic mode 
read when the KB Mode Control is off. Contents of the error logs are unknown 
on power-on. 

An Am2960 EDC chip is used for error detection and correction. The EDC 
contains the logic necessary to generate check bits on a 16-bit data word 
according to a modified Hamming code. Tne EDC will correct an single-bit 
error and will detect all double and some triple-bit errors on data-read 
operations. 

If the SMM detects a single bit error on a read cycle, it will correct the 
word, generate a new check code and write the corrected data word/check code 
to the address specified by the read cycle. 

Maximum transfer rate during a read cycle is 312.5 nanoseconds (625 ns for 
read with corrected error). Minimum read access time is 312.5 ns (437.5 for ,/- 
j read with corrected error) . V.v 

Maximum transfer rate for a write cycle is 312.5 nanoseconds (625 ns for byte 
write.) . 
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2.10 LINE INTERFACE MODULES (LIM) 

Multiple versions of this board will be developed. LIMs have their own space 
within the DI and up to eight (8) can be configured within a single DI. Each 

LIM interfaces to the LIM Bus and can drive external lines. 

i ' 

A LIM can be connected to only one CIM at a time. It can have from two to 
four ports, each of which connects to a communications line or a unit record 
device. 

All LIMs employ VLSI line controllers with the following programmable features: 

- Baud Rate/Channel/Receive or Transmit 

- External/Internal Clock 

- Synchronous (Bit or Byte) and Async 

- Auto Echo and Loop Back 

- Interrupt (Vectors, Enable) 

- Modem Control Response 

- CRC-16 or CCITT CRC Generation 

- Mark or Space Idle 

- Odd or even line parity 

The first release will include the LIM types described below. 
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2.10 LINE INTERFACE MODULES (continued) 
2-Channel RS449 LIM 

This is a two-channel device which provides, as standard, two DTE connections 
that comply with all the requirements and options for the RS449 primary 
channel. Both RS422 and RS423 electrical standards are supported via a 
strappable option. 



FEATURES SUPPORTED 



COMMENTS 



f 



RS449 PRIMARY CHANNEL DTE + RS422 



RS449 PRIMARY CHANNEL DTE RS423 



RS449 PRIMARY CHANNEL DCE + RS422 



RS449 PRIMARY CHANNEL DCE + RS423 
RS449 SECONDARY OR BACKWARD 
CHANNEL, DTE, RS423 



RS449 PRIMARY CHANNEL WITH (SDCD) 
FLOW CONTROL. DTE, RS422 



6 WITH RS423 OPTION 



RS366A AUTO DIAL OPTION 



X.24/X.21 PARTY LINE 



STANDARD 



STANDARD WITH STRAPS 



REQUIRES MODEM ELIMINATOR 



AS FOR (3) WITH STRAPS 



CABLE ADAPTOR 9 PIN TO 37 PIN 
CABLE ADAPTOR 37 PIN AND y fIn 
TO 37 PIN.PSEUDO STANDARD ONLY 



AS PER 6 WITH RS423 STRAPS 
REQUIRES SOFTWARE AND ADAP1UK 

(REF. 3.1.1.7) 

REQUIRES ADAPTOR, STRAPS 



AND SOFTWARE 



v y 



Each of the features listed require one of the two available channels on this 
LIM. 

In asynchronous mode this LIM will support both data rates of 50 to 
38.4Kbps per channel, and different receive and transmit rates (e.g. 
send 1200 baud, receive 75 baud) . 

- In synchronous mode this LIM will support up to 64Kbps with a local 
clock; with an external clock, up to 250Kbps can be supported by the 
hardware. As a synchronous DCE, this LIM will supply a transmit 
clock. 



i 



4-Channel RS449 LIM 

This LIM will provide both RS232/V-28 and RS422/V.11 electrical interfaces. 
The physical interface will be compatible with RS232A.24 (via an adaptor 
cable if necessary) , with X.21, and with X.24. Allowance will be made for 
both DTE/DCE operation and both local or external clock sources. 
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2.10 LINE INTERFACE MODULES (continued) 
4-Channel RS232 LIM 

RS232 will support per channel all those DTE signals defined in_"RS232 
application notes option D" VIZ: * 

32 

NAME 

Ground 
Logic RTN 
Transmit Data 
Receive Data 
Requst to Send 
Clear to Send 
Data Set Ready 
Data Terminal Ready 
Ring Indicator 
Carrier Detect 
Transmit Clock (DTE) 
Transmit Clock (DCE) 
Receive Clock (DCE) 

The RS232 implementation will allow different transmit and receive rates as 
used by V.23 style modems. 

Signalling rates supported will range from 50 bps to 38.4Kbps asynchronous and 
56Kbps synchronous. With external clocking, or using non standard baud rates, 
speeds up to 250Kbps can be supported. The higher baud rates will limit the 
cabling (as wave shaping will be used) . 






CCIT 


RS232 


CIRCUIT 


CIRCUIT 


101 


AA 


102 


AB 


103 


BA 


104 


BB 


105 


CA 


106 


CB 


107 


CC 


108.2 


CD 


125 


CE 


109 


CF 


113 


DA 


114 


DB 


115 


DD 



4-Channel X.24/X.21 LIM 

This will support the following as a DTE. 

X.24 

CIRCUIT 



G 

T 
R 
C 
I 
S 



NAME 

Ground 

Transmit Data 
Receive Data 
Control 
Indication 
Signalling Clock 



The electrical level will be RS422/V.H- All of the above will be supported 
as either Data Communication Equipment (DCE) or Data Terminal Equipment (DTE) . 
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2.10 LINE INTERFACE MODULES (continued) 

V 



*~j V'35 LDj Q. 



This 2-Channel LIM is based on the RS449 LIM with appropriate changes to the 
electrical and physical interfaces to comply with OCITT V.35 + APPENDIX II, 
and ISO 2593-1973 (E) for all CCITT-specified circuits. 

Signalling rates up to 108KHz will be supported with external (DCE) supplied 
clock. 



w> 



f \ 



/0Q65y Page 2-18 



14 March 1984 



o 



3.0 DISTRIBUTED COMMUNICATIONS NETWORK SOFTWARE (DCNS) 

DCN software (DCNS) resident in the DIs provides four major functions: 

System management software - implementation of software to 
create and maintain a system environment for the other' functions. 

CDNA layer software - implementation of the Control Data Network 
Architecture (CDNA) layer functions. 

CDNA network management software - implementation of the Control 
Data Network Architecture (CDNA) network management functions. 

Interface software - implementation of interface software to 
connect foreign networks, systems, and devices to the DCN. 

The diagram belows illustrates the relationship between the major DCN 
software functions. 

+ + 

//////////////////////////////// /// 
//// SYSTEM MANAGEMENT SOFTWARE // 

////////////////////////////// ////// 
/////// -H-=====-==^^^=^======^— ==^=~=^^ ' J ' / ' / ' / /; 

/////' 
/ / / / /I 
///// 

/ / / / n 

///// 
/////! 

///// 
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MANAGEMENT 11 '•'•///// 

•//// /I 

software :: a/ ////„ 

/ / / / /I 

///// 
/ / / / /J 

///// 

:++=================«==++:: / / / / /i 



j*«» 



> 



!/ 



W ////// ii ■ 

///////ii* 
!//• 

// 
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// 

!// 



* * 



* * * 



* * * 

* * i 



* * * 



* * * 



* * * *] 



* * 



I I * * * 



* * * * 
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*********** 
********** 

* * * * INTERFACE SOFTWARE 
*******************! 
********************* 

=++* * * * *! 
* * * * 
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HIGHER LAYER 
SOFTWARE 



• * * 

• * * 



* * *] 
* * 

* 

i* * * * *' 



// 
!// 

// 
!// 

// 
I// 
// 

:// 



LOWER LAYER SOFTWARE 



//////////////////// ////////////////,, 

////////////////////////////// ////// 

/////// /////////////////////////////' 
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3.0 DISTRIBUTED COMMUNICATIONS NETWORK SOFTWARE (DCNS) (continued) 

,4~\ System management software operates initially to create an operational ^. 

l \ f environment in a DI. Software resident in the ROMs operates in (JJr 

conjunction with the Initialization M-E to load a DI; the following 
components then put the DI into an operational state: . 

Initial Loader 

System Ancestor 

Configuration Procurer 

Section 3.1 describes the network load & startup process. 



Once the network is operational, system management software maintains the 
environment for the layer and network management functions; operational 
system management components are: 

Executive 

Common Subroutines 

r - ^ - On-line loader 



,/ 
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Diagnostic Management Services ^ ' 

Failure Management 

Every DI contains all of the operational system management software. 

Section 3.2 provides an overview of the operational system management 
software components. 
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3.0 DISTRIBUTED COMMUNICATIONS NETWORK SOFTWARE (DCNS) (continued) 

CDNA layer software provides communication between systems, terminals, 
applications, and end users connected to the DCN. DCN implements one or 
more software components for each layer to provide the functions required 
by CDNA for that layer, as illustrated below. 



c 



CDNA LAYER FUNCTIONS 
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CDNA 

HIGHER 

LAYERS 


7 I 
6 i 
5 ! 


HIGHER ! 
LAYER I 
GROUP i 


CDNA 


4B, 


X.25 SUPPORT LAYER ! 


MIDDLE 






LAYERS 


4 


TRANSPORT ! 




3B. 


INTERNET I 


CDNA 


3A 


! INTRANET I 


LOWER 
LAYERS 


2 ' 


! LINK I 




1 


! PHYSICAL ! 



DCN SOFTWARE COMPONENTS 



- Interactive Transfer 
Service (ITS) 



-X.25 Support Layer 



- Generic Transport 

- Xerox Transport 

- Internet 



- Intranet 



HDLC SSR 
Ethernet SSR 



- HDLC CLM Driver 

- Ethernet Driver 



Every DI contains software components for layers 1 through 4B. HDLC 
and/or Ethernet components are present for layers 1 and 2. These layers 
are necessary in order to support network management functions. 

DCN layer components are discussed in Section 3.3. 
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3.0 DISTRIBUTED O0MMUNICATIONS NETWORK SOFTWARE (DCNS) (continued) 

CDNft. network management is provided by software components called 
Management-entities (M-Es) . Management-entities are the following: 



handles routing of data within the catenet. 

i ' 

maintains a directory of Titles and 
Addresses. 

provides access to secondary storage files. 

processes network commands. 

provides logging of messages. 

allows data to be "echoed" back to the 
sender. 

provides for communication of error 
conditions. 

operates as part of the DI load & startup 
process. 

Every DI contains all or some portion of the above M-Es. Whether or not 
a given DI contains the full-blown version of a particular M-E depends on 
whether that DI is configured to support both an active ("independent ) 
and a passive ("dependent") role in network management or just a passive 
("dependent") role. Generally, DIs that have access to secondary storage 
are the best candidates to be configured in support of active network 
management roles. 

Section 3.4 provides an overview of each Management-entity and further 
elaborates upon the distinction between active and passive roles. 



Rxiting M-E 
Directory M-E 

File Access M-E 
Command M-E 
Log M-E 
Echo M-E 

Error M-E 

Initialization M-E 
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3.0 DISTRIBUTED CttMJNICATIONS NETWORK SOFTWARE (DCNS) (continued) 

Any system that contains at least the CDNA layer and network management 
functions defined above is said to be a "CDNA system." In Release 1, 
each DI is therefore a CDNA system; the C170 mainframe is not a*CDNA 
system because it does not contain any of the CDNA layers or management 
functions. In contrast, the C180 mainframe, which will be supported in a 
subsequent release, does contain CDNA layers and management functions and 
is therefore a CDNA system. 

CDNA implementations, such as DCN, are expected to facilitate 
interconnections with non-CDNA systems; DCN provides this capability via 
the DCN interface software. 



o 



DCN interface software supports three major external interfaces, 
follows: ~~ 



as 



C170 interface 



^kujJr 



X.25 interface 



o 



allows DCN end users to access services 
of a C170 host connected to the DCN. 
C170 interface software is also used to . 
access C170 host resources for use by the 
DCN network management functions. Section 
3.5 provides an overview of this 
interface. 

provides a mechanism whereby two or more 
physically disjoint DCN networks can be 
logically connected via an X.25 PDN or 
X.25 trunk. This same interface 
provides, to foreign systems and 
networks, a transparent access to the 
DCN. Section 3.6 provides an overview of 
this interface. 

allows DCN end users to access the 
services of the DCN via terminal devices 
connected via asynchronous communication 
lines. Subsequent releases will also 
support synchronous communication lines. 
Section 3.7 provides an overview of this 
interface. 

The C170 and X.25 interface software both include a "gateway function" to 
permit communication between unlike architectures. DCN implements the 
"gateway function" by software components called "transforms" that 
provide a mapping between the services offered by DCN and those offered 
by the other architectures. Gateway functions and the associated 
transforms are further discussed in Sections 3.5 and 3.6. 



D 



Terminal user interface 
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3.0 DISTRIBUTED OOMMUNICATIONS NETWORK SOFTWARE (DCNS) (continued) 

(f~\ The diagram below illustrates the three major external interfaces, 

^—^ including the gateway functions. 
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The specific functional role of a DI determines which DCN interface 
software components are resident in that DI. 

If the role of a DI is to interface a C170 mainframe to the DCN, the 
DI will contain C170 interface software and the DI is called a 
Mainframe Device Interface (MDI) . 

If the role of the DI is to interface terminals to the DCN, the DI 
will contain terminal interface software. Such a DI is called a 
Terminal Device Interface (TDI) . 

If the role of a DI is to interface an X.25 network to the DCN, the 
DI will contain the X.25 interface software and the DI is called a 
Network Device Interface (NDI) . DIs that interconnect HDI£ and 
Ethernet networks do not require any specific non-CDNA interface 
software; these DIs are also called NDls. 

Because of the modularity of the DI hardware and software design, DIs can 
be configured to support more than one type of function. For example, a 
DI can be configured with both the terminal and mainframe support 
hardware/software. The role of such a DI becomes Mainframe and Terminal 
Interface (MTI) . Other varieties of hybrid DIs are possible. 
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3.1 SYSTEM MANAGEMENT OF DI LOAD & STARTUP 

This section describes the DCNS components involved in bringing the DI £?\ 
hardware to an operational state. Components are introduced and V^ 

described in the order in which they operate during network loading and 
startup. * 

In Release 1, a C170 mainframe is the initial source of load files and is 
the only destination for dump files; consequently the load process begins 
with interaction between a C170 mainframe and a C170 MDI that is 
connected via a channel interface. 

A program called INITMDI in the C170 mainframe is activated as the result 
of a request from the MDI; INITMDI is responsible for executing the 
Initialization protocol with the MDI across the channel. Further 
information on the process of loading across the channel will be supplied 
in a future update to this document; the remainder of this section 
assumes that at least one MDI is loaded and ready to load other DIs in 
the ca tenet. 

In the descriptions that follow, the DI to be loaded is referred to as 
the "remote DI," while the DI performing the load (and optionally 
receiving the dump) is referred to as the "local DI." A local DI can 
load a remote DI only through two types of network solution, namely the 
Ethernet and an HDLC line. Since the remote DI initially contains only 
the code that is burned into its ROMs, loading over an X.25 packet 
network is impractical. 

U Each remote DI must receive its load information from a neighbor that is \J 
already loaded and operational. A remote DI sends a "Help Request" to 
all of its neighbors on one of the network solutions to which it is 
connected; each neighbor either ignores the "Help Request" or 
acknowledges by sending a "Help Offer." If more than one "Help Offer" is 
received, the remote DI accepts help from a single neighbor by sending a 
"Help Accept." A "Help Offer" contains a priority field that will, in 
subsequent releases, be used to determine which neighbor should be 
selected. 

If the DI to be loaded does not receive a "Help Offer" from at least one 
neighbor, it sends another "Help Request" to all of its neighbors on 
another network solution to which it is connected. This process is 
repeated until a "Help Offer" is received. 
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3.1 SYSTEM MANAGEMENT OF DI LOAD & STARTUP (continued) 

Each DI contains software in read-only memory (ROM) to provide the 
(f\ functions needed for initial self -test and loading of the DI; these j~* 

**—* functions are invoked after a power failure or a reset due to any other XJ 

failure, such as hardware and software failures. 

The software contained in ROM consists of two major components: 

The ROM On-Board Diagnostics , which: 

Check the ROM memory for integrity; 

Determine which cards are physically present in the DI and 
builds the hardware configuration table, also known as the DI 
Card Map; and 

Test the individual hardware cards. 

The ROM-based Initialization Software , which: 

Locates possible load sources (e.g connected networks) and 
requests help in loading the DI from the selected source, and 

Provides an optional dump of the DI, with the assistance of the 
selected source. 






3.1.1 ROM On-Board Diagnostics / - 

The ROM on-board diagnostics are self-test diagnostics that check the DI 
hardware for correct operation. They are run every time the card is 
reset. On-board diagnostics exist on the following cards: 

o MPB 

o MCI 

o ESCI 

O CIM 

O SMM 

On-board diagnostics on the MPB board are responsible for testing the MPB 
and PMM boards. In addition, they are responsible for coordination of 
on-board diagnostics on the other cards. The MPB on-board diagnostics 
are responsible for construction of the DI Card Map, which contains a 
list and status of cards physically present in the DI; it also determines 
the total SMM address space based on the SMM cards present and 
operational in the DI. 

On-board diagnostics on the other cards are initiated by the MPB on-board 
diagnostic based on information from well-known ROM locations on the 
board under test. They test the hardware present on the card and provide 
its status to the MPB on-board diagnostics. 
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3.1.2 ROM-based Initialization Software 

The ROM-based initialization software consists of the following two parts: 



MPB ROM Bootstrap 



Card-specific Bootstrap 



C 



The MPB ROM Bootstrap in the remote DI is 
responsible for coordination of the bootstrap 
load process and execution of the CDNA 
Initialization protocol with either a peer 
Initialization M-E in the local DI or INITMDI 
in the C170 host. The MPB ROM Bootstrap 
includes the following major components: 

Main Bootstrap Controller 
Initialization Bootstrap 

Card-specific Bootstraps exist in ROM on the 
following cards: 

CIM 

ESCI 

MCI 

A Card-specific Bootstrap is called by the Main 
Bootstrap Controller as a subroutine and, in 
turn, calls the Initialization Bootstrap 
software to help in loading the DI. The 
Card-specific Bootstrap provides the layers 1, 
2, and 3A functions for the network solution 
connected to the card. In the case of the CIM 
Card-specific Bootstrap, up to two connected 
HDLC lines are tried, one at a time, according 
to switch settings. 

The reader might note that the MPB ROM Bootstrap is the DCNS 
implementation of the dependent Initialization M-E in the remote DI, as 
described in the CDNA GDS. The Initialization M-E in the fully loaded 
local DI functions as the independent Initialization M-E. 
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3.1.2.1 Main Bootstrap Controller 

The Main Bootstrap Controller is invoked by MPB on-board diagnostics to 
"| read the "boot enable" switch on the MPB card to determine the first card f\ 
J* to be used for the bootstrap load. If the selected card is present and \J> 

operatiional (as determined from the DI Card map) , the Card-specific 
Bootstrap from the card's ROM is moved to SMM and an attempt is made to 
load the DI across this card by using the Card-specific Bootstrap as a 
subroutine. 

If the attempt is unsuccessful, other cards that are potential bootstrap 
sources are selected and the load attempt is retried. Cards are selected 
in numerical card slot order. 

If all attempts fail, the Main Bootstrap Controller displays an error 
code via the light indicators on the MPB Card and halts the processor. 
This results in a Dead man time out, which re-starts the whole process by 
starting the on-board diagnostics. 

3.1.2.2 Initialization Bootstrap 

The Initialization Bootstrap is called as a subroutine from the 
Card-specific Bootstrap; it broadcasts a Help Request on the network 
solution connected to the card across which the load is being attempted. 
It waits for a certain amount of time for possible Help Offers; selects 
one based on the priority included in the Help Offer; and sends a Help 
Accept to the selected system. 

The Initialization Bootstrap uses the Auto Dump table to determine if the r ~^ 

DI memory is to be dumped before loading the DI. The Auto Dump table 

resides at a well known address and is protected via a checksum. The 

table is built by the operational software present in DI prior to this 

load. It contains a list of portions of DI memory to be dumped. If the 

Auto Dump table does not exist or is invalid, a default Auto Dump 

consisting of all of SMM and the MPB RAM is sent; RAM on other card types 

is not included in the default Auto Dump. 

The Initialization Bootstrap calls subroutines in the Card-specific 
Bootstrap to dump the DI memory and then load the DI. It executes the 
CDNA Initialization protocol to do so. 
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3.1.3 Initialization M-E 

Each MDI and NDI that is loaded and operational, contains a copy of the f~- % 
independent Initialization Management-entity (M-E) , which is used to dump \^J 
and load other Dls. 

The independent Initialization M-E in the local DI uses the File Access 
M-E to read the load file from a C170 mainframe and executes the 
Initialization protocol with the MPB ROM Bootstrap (dependent 
Initialization M-E) in a remote DI in order to load the remote DI. Ihe 
Initialization M-E uses lower layers (layers 1-3A) to send and receive 
data to and from the remote DI. 

Lower layers associated with Ethernet do not have to do anything special 
to effect loading of a remote DI. Lower layers associated with the HDLC 
lines have to prime the line for the Initialization protocol by using 
"RIM" and "SIM." 

The following is a step-by-step description of the process used to load a 
remote DI, from the local DI's perspective. 

1. The network solution connecting the local and remote Dls is 
configured in the local DI via a configuration command. As a 
result, the lower layer software is initialized for data 
transfer on the network solution. 

2. The Initialization M-E in the local DI informs its lower layers 

of its willingness to receive data from any connected network r 

f| solution. Information in the protocol header of the incoming f | 

^^ data is used to determine if the data is addressed to the V/ 

Initialization M-E. 

3. The Initialization Bootstrap in the remote DI sends a Help 
Request, which is received by the Initialization M-E in the 
local DI. 

4. The Initialization M-E uses the File Access M-E to read a file 
that contains information about Dls that need a non-default 
version of the load file as well as a list of Dls that should 
not be loaded. This file is further described in the section 
on Network Definition. 

If no restriction is found on loading that remote DI, the 
Initialization M-E sends a Help Offer. The Help Offer contains 
a priority field which, in Release 1, can contain only a single 
value; future use of this field remains to be determined. 

5. The Initialization Bootstrap in the remote DI decides if it 
wants to accept the Help Offer. If so, it sends a Help Accept 
to the Initialization M-E in the local DI. 
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3.1.3 Initialization M-E (continued) 

6. After receipt of the Help Accept, the Initialization M-E in the 

I local DI uses information in the original Help Request to | | 

-J determine the need to dump the memory of the remote DI; the ^S 

criterion used in this determination is the reason for loading 
the remote box. * 

7. If the remote DI memory needs to be dumped, the Initialization 
M-E uses the File Access M-E to create a new dump file on an 
accessible C170 mainframe. An Initiate Auto Dump is sent to the 
remote DI, which responds by sending dump data. 

The Initialization M-E in the local DI and the Initialization 
Bootstrap in the remote DI follow the Initialization protocol to 
dump the memory of the remote DI. The Initialization protocol 
allows for partial and full dump. Throughout this process, the 
Initialization M-E uses the File Access M-E to write dump data 
to the dump file. 

8. Once the dump is complete or if the dump is not needed, the 
Initialization M-E uses the File Access M-E to find the 
appropriate load file on an accessible C170 mainframe. It uses 
the File Access M-E to read the load file and the lower layers 
to transmit the information to the remote DI. The 
Initialization M-E and the Initialization Bootstrap use the 
Initialization protocol to manage transmission of load data. 
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3.1.4 Startup 

K.P This section provides an overview of the three software components that y_j} 

execute immediately after the DCN software has been loaded into DI 
memory. These three components bring the loaded software to a fully 
operational state. The three processes are the Initial loader /System 
Ancestor , and Configuration Procurer and execute successively in this 
order . 

3.1.4.1 Initial Loader 

The Initial Loader is the first software loaded into the DI by the 
Initialization Bootstrap. The Initial Loader arrives as a prelmked 
MC68000 absolute record ready for execution. The Initial Loader is given 
control by the Initialization Bootstrap after all software has been 
placed into DI memory. 

The first function of the Initial Loader is to absolutize the loaded 
software modules. This function includes: 

allocating memory for the modules, 

moving code and data into the allocated memory, and 

linking external references. 

^ The second function involves the initialization of the Executive, which _^ 

O includes: \j 

initializing the system vector and configuration tables, 

creating buffer and memory pools, and 

setting up hardware timers. 

The Initial Loader then starts the System Ancestor as a task. This 
process starts both the Executive and the System Ancestor. At this 
point, all software is ready for startup; the Executive is initialized 
and running; and the System Ancestor has been started as a task. 
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3.1.4.2 System Ancestor 

:^~\ The System Ancestor's function, during initialization, is to start the ^ 

■V> tasks associated with a subset of the loaded software. - This subset \J) 

.consists of the software common to all DI variants plus the software 
required to drive the network interface that was used as the load source. 

The System Ancestor makes successive calls to the Initial loader to 
obtain information about the next task to be started. This information 
includes the task's transfer address, stack size, and priority. This 
information is given to the Executive for each task as it is started. 
Each time the System Ancestor calls the Initial loader, it determines if 
the task returned is the System Ancestor itself. If so, this informs the 
System Ancestor that its function is complete with respect to DI 
initialization. The System Ancestor also plays a role in the management 
of failures; this role is discussed in the next section. 

The Initial loader works off a list of loaded software, called the Module 
Name List. The System Ancestor task's position within the Module Name 
List differentiates tasks started directly by the System Ancestor from 
tasks started through some other process such as configuration commands. 
Thus, some tasks are started as the result of the initialization process; 
others are started as the result of the configuration process; and yet 
others are started as the result of some other stimulus. 

When the System Ancestor completes its initialization function, the 
minimum set of system tasks have been started. 

'L j 3.1.4.3 Configuration Procurer ^ ^ 

The Configuration Procurer uses the services of the File Access M-E to 
read a file containing the configuration commands specific to the DI 
being initialized. The Configuration Procurer issues an Open File 
request that specifies the type of configuration file (via the file-type 
Title" parameter) and the System ID of the system being configured (via 
the "file name" parameter) . 

The Configuration Procurer submits the commands to the Command M-E for 
processing by the responsible command processors. In this way, the set 
of software and tasks that supports the DI's unique configuration are 
started . 

The Configuration Procurer receives command responses for each command 
submitted and issues log messages for those commands that were not 
processed to normal completion. Commands in error do not prevent 
execution of subsequent commands. Once a DI is operational, 
configuration command errors can be corrected manually via the operator 
interface. 

The execution of the Configuration Procurer can be bypassed by creating a 
configuration file containing a "Bypass Configuration" command; all DI 
configuration information can then be entered manually by an operator. 
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3.2 SYSTEM MANAGEMENT 

The components described in this section provide support for the layer 
and network management functions during normal network operation. 



DCNS provides system management functions, as follows: 



Executive - 



Common Subroutines - 



provides the functions needed in a 
multiprocessing/multitasking software 
environment. 

provide commonly used functions and 
CYBIL interfaces to Executive 
subroutines. 



On-line loader - 



used to load and remove software 
modules in an operational on-line 
environment. 



o 



Diagnostics Management - 



Failure Management - 



provides the framework for execution of 
on-line diagnostics 

provides detection, logging, and 
recovery of hardware and software 
failures 
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3.2.1 Executive 

The DCNS Executive provides, to all processes, the kernel set of 
primitive functions required in a multiprocessing/multitasking software 
environment. These functions include such services as: 

- CPU scheduling 

- exception processing and interrupt vector services 

- intertask communication 

- memory and buffer management 

- timer services 

Statistics, journaling, debug, and gueueing services are also provided, 
although they are not at present used. 



O 
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Code for the Executive can reside within the MPB RAM, SMM, or PMM if 
available. The Executive executes on the Main Processor Board (MPB) of 
the DI. 

The MPB's MC68000 microprocessor is always in one of three processing 
states: 

normal associated with instruction execution; the memory 

references are to fetch instructions and operands, and 
to store results. 

exception associated with interrupts, trap instructions, 
tracing and other exceptional conditions. 

halted an indication of catastrophic hardware; only an 
external reset can restart a halted processor. 
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3.2.1 Executive (continued) 

The processor operates in one of two states of "privilege:" | 

supervisor the higher state of privilege. All instructions can 
be executed in the supervisor state; all exception 
processing is done in the supervisor state. 

user the lower state of privilege. Some instructions which 
have important system effects are privileged and 
cannot be executed in user state. Once the processor 
is in the user state, only exception processing can 
change the privilege state. 

The Executive is responsible for the allocation of MPB MC68000 processor 
and system memory between two classes of software processes: 

Exception processors - Exception processors are high-priority 

predefined code sequences that are given CPU control 

by the hardware when an exception is sensed by the 
CPU. A hardware interrupt is an example of an 
exception. 

Tasks - Tasks provide network layer and management functions 
during that period when the CPU is not busy servicing 
exceptions. 

OThe Executive provides interfaces for defining both types of processes. #"i 
It is the Executive's responsibility to schedule the CPU between the \^} 

tasks. 
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3.2.1.1 CPU Scheduling 

/ \ Tasks are scheduled to the CPU based on their task priority. Tasks with |-v 
1 %J the same priority are scheduled to the CPU in a round-robin fashion. The \J 

CPU scheduling algorithm is executed when the currently running task 
completes execution or when a higher priority task is waiting for the 
CPU. The Executive will recognize and schedule the higher priority tasK 
under the following conditions: 

the currently running task has exceeded its time slice; 

the currently running task makes a request for Executive 
services; 

an exception processor completes processing. In this case, the 
Executive schedules the higher priority task instead of 
rescheduling the task that was interrupted. 

The Executive may temporarily reduce a task's priority as a result of 
executing the CPU scheduling algorithm. This is only done when it is 
determined that a task is using an inordinate amount of CPU time. In 
this case, a task's priority is reinstated at that time when the task has 
completely processed all of its queued intertask messages and has entered 
a waiting state. 

Exception processors are given CPU control whenever the hardware senses 

an exception event. Exception events are prioritized by the hardware. 

This provides resolution of simultaneous exception events and also allows 
{ a lower priority exception processor to be interrupted by a higher ■ 

\- J priority exception processor. Details of MC68000 exception processing 

are described in the MC68000 16-bit Microprocessor User Manual. 

CPU scheduling is currently undergoing design; some of the questions 
remaining to be answered are: 

When the priority is lowered, is the task put at the head or tail of 
the queue containing tasks at the lowered priority? 

What is an "inordinate" amount of time? 

What happens if the task gives up the CPU before the ITM queue is 
empty? 
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3.2.1.2 Exception Processing 

Exceptions can be generated either externally or internally. Externally I ) 
generated exceptions are: ^~- y 

reset requests 

interrupts from peripheral devices 

bus errors 

Internally generated exceptions may arise as the result of execution of 
an instruction. The TRAP, TRAPV, CHK, and DIV instructions can generate 
an exception as part of their execution. Other instructions can generate 
exceptions: 

as the result of being an illegal instruction 

by attempting word fetches from odd addresses 

by attempting to execute a privileged instruction while the 
MC68000 processor is in the non-privileged state. 

The Executive maintains an exception vector table that maps the exception 
vector number to the entry point of the corresponding exception 
processor. The vector table contains 255 entries and is initialized as 
part of the Executive initialization process. 

\J Exceptions not known to the Executive at initialization time are mapped 

to the spurious interrupt processor; such exceptions are normally 
interrupts from peripheral devices that are not yet initiallized. When 
that device is undergoing initialization, an Executive service is 
provided to change the device's exception vector from the spurious 
interrupt to the appropriate peripheral device interrupt processor. 

When peripheral devices interrupt the CPU, they present an exception 
vector number that is used as an index into the exception vector table so 
the appropriate interrupt exception processor can be executed. Tne 
Executive provides services for making entries into the exception vector 
table for purposes of servicing hardware interrupts and software-defined 
TRAP levels. 

All exception processors execute in the MC68000 supervisor state and 
utilize the system stack. 
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3.2.1.3 Inter-Task Communication 

The main function of tasks is to process intertask messages sent to them 
by exception processors or by other tasks. In support of this function, 
/ | the Executive provides services for sending and receiving intertask (f\ 

KJ messages. Bach task has two associated intertask message queues that are \> 

maintained for the task by the Executive. Tasks execute in the MC68000 
user state and utilize their own associated stack area. *; 

The Executive maintains a list of Task Control Blocks. Each entry in the 
list contains control information for one of the currently defined tasks. 

Associated with every task is a task stack and task priority. 

The task stack is used to hold procedure automatic variables and to 
facilitate the linking/unlinking of nested procedure calls. The task 
stack size is set once at task startup time and remains unchanged for 
the life of the task. There is no mechanism to prevent a task from 
overflowing its stack space; there will, however, be methods for 
detection, isolation, recovery, and prevention of stack overflow. 

The task priority is used by the Executive to determine the next task 
to be scheduled for the CPU. Tasks with higher priority are given 
first consideration. Task priority is specified at task startup time 
and can also be altered dynamically via an Executive service. 
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3.2.1.4 Buffer Management and Thresholds 

C Buffer Management is the Executive service that supports the dynamic --. 

J) allocation and deallocation of buffers used to hold message data. The I ) 
design of the Executive buffer management service considers both system 
performance and the unique processing requirements of a layered, 
architecture. 

Every attempt has been made to minimize or eliminate movement of data 
within system memory. Such functions as adding or deleting message 
headers or trailers do not affect the residence of message data. 
Multiple copies of messages are maintained at the logical level by 
utilizing one physical copy and an associated usage count. 

To support this level of buffer management sophistication, a descriptor 
buffer design was chosen. Associated with every data buffer is a 
descriptor buffer that keeps track of buffer chaining, usage counts, data 
offsets, data counts, and pointers to associated data buffers. Both 
descriptor and data buffer sizes are configurable. 

The Executive provides services to obtain and release buffers. The 
services of the Executive buffer management are augmented by a set of 
common subroutines that perform the high frequency functions on buffers, 
such as addition/deletion of message headers/trailers, message 
fragmentation/assembly, logical/physical message copy, etc. 

The Executive can be configured to support any number of buffer 
thresholds. Both the number of thresholds and the total number of 
g\ buffers available at each threshold level are configurable. ^""V 

The Executive uses the configured parameters while processing "buffer 
get" requests. The user process must specify a buffer threshold along 
with every "buffer get" request. The Executive will honor the request 
only if the number of currently available buffers is greater than the sum 
of the number of requested buffers and the configured threshold value. 

Threshold level zero is predefined by the Executive; requests at 
threshold level zero are always honored. If enough buffers are not 
available to satisfy a threshold level zero request, buffer space is 
allocated from global memory until enough buffers exist to honor the 
request. All common subroutines that potentially need to obtain an 
Executive buffer, require a buffer threshold parameter. 

Buffer threshold use is currently undergoing design; some of the 
questions to be answered are: 

How is buffer threshold used? 

An overview of memory management should be supplied. 
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3.2.1.5 Timer Services 

C I The Executive provides a set of timer services that allow a process to 
^ request that a specified subroutine be called. In addition to specifying 
the subroutine to be called, the user can also optionally specify a 
parameter to be included with the subroutine call when the subroutine is 
activated. 

The user can request that the specified subroutine be called: 

at a specified time with a time resolution of one minute 

periodically 

after an interval of elapsed time. 

The service also exists to cancel a previously issued timer request. 

All timers are accurate to one millisecond. 



3.2.1.6 Non-buffer Memory Management 

The Executive provides a service whereby a variable-length memory exent 

may be obtained by processes requiring non-message memory areas. 

Variable-length memory extents can be obtained directly through the use 

of an Executive-supported service or via the CYBIL ALDXATE statement. r - A 

The Executive internally utilizes global memory for allocating and v^_ y 

deallocating memory space to and from the data buffer pool. 
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This feature may or may not be retained; investigation is currently 
underway. 



/0061y Page 3-22 



16 March 1984 

3.2.2 Common Subroutines 

("*>) The Common Subroutines are a collection of frequently used functions, 
■ J which can be grouped into the following categories: 

CYBIL interface to Executive functions t 

Queue management 

Task management 

Timer services 

Miscellaneous Executive functions, such as 

obtaining/releasing memory, start/stop of tools, etc. 

Common Type definitions 

Non-Executive functions 

Tree (table) management 
Buffer management 
Operations on integers 

3.2.3 On-line loader 

The On-line Loader provides the following services to other DI tasks: 

Translate entry point names and module names into tasks/addresses 
Interlock use of modules to prevent deloading of modules while 

o stiUinuse o 

Provide a status interface for communication between loaded 
modules and operator status enquiries. 

On-line Loader functions are: 

Load provides loading of modules by entry point name 
and module name. The load process consists of 
reading the object module file, allocating memory 
for the module sections, moving code and data 
into the sections, and linking external 
references., 

Deload provides deloading of unused modules. The deload 
process consists of dereferencing other modules, 
deallocating memory for the module sections, and 
removing entry point names. 

Translation provides the entry point name and module name 

translation to already loaded modules or modules 
to be loaded. It also provides translations to 
support the status interface, checksum all loaded 
modules, validate the program counter, and return 
transfer addresses. 
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3.2.4 Diagnostics Management Services 

Diagnostics Management Services (DMS) co-ordinate on-line diagnostics and 
(f~J provide support for failure management software. DMS consists of the ^v 

V_/ following components: v^ 

* ■ 

DIAG_INIT_PR0CESSOR reviews the final status of on-board 
— diagnostics. 

GEN DIAG COMMAND builds a "send" command for the Attention 
- ~ Sequence of Auto- Initiate processors. 

MONITOR ON BOARDS Starts and monitors an on-board 

~ ~ diagnostic for a specific device while 
operating in an on-line environment. 

On-line diagnostics are SMM-resident programs that test individual boards 
within a DI while the remainder of the DI remains operational. Running 
the diagnostic may temporarily cause the system to stop normal processing 
in cases where there is only one board of the type being diagnosed; 
however, the board's controlware is not disturbed by the diagnostic so 
that it can be returned intact to the system when the diagnostic 
completes. 

On-line diagnostics are loaded on an as-needed basis to test both the DI 
hardware elements and their interfaces with external devices such as C170 
.. mainframe channel, Ethernet Transceiver, modems, and communication 
fr x lines. The following on-line diagnostics are planned for Release 1: ^ 

x - ciMO - tests a CIM and its associated LIMs, via standard v 

controlware resident in the CIM. CIMO uses loop-backs 
provided in the LIMs and attached modems to isolate 
problems in the communication lines. 

ECHD - tests the DI-to-DI link, across either Ethernet or 

communications line/modems. Testing consists mainly 
of echoing data from one DI to the other. 

ESCO - tests the ESCI board and the Ethernet Transceiver via 
the standard ESCJ -resident controlware. ESCO uses 
loopbacks provided by the ESCI module and Ethernet 
Transceiver to isolate problems in the Ethernet. 

MCIO - tests the MCI board. Testing is done from the MPB, 

using the MPB-resident controlware. Testing simulates 
customer operation. 

IMMO - tests the PMM board; testing is done from the MPB. 

SMMO - tests the SMM board. Testing is done from the MPB. 
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3.2.5 Failure Management 

O Failure management software is concerned with the detection, logging, and g^ 
recovery of DCN hardware and software failures. \^J 

Failure detection includes the following aspects: * 

1) How each failure is detected. 

2) What information is available at the time of failure; for 
example, what software component was executing; what memory 
address was being accessed. 

3) How severe the failure is; dependent upon the type of failure, 
recent occurrences of the same failure, and which software 
component experienced the failure. 

Failure logging includes the following aspects: 

1) which failures are reported 

2) when failures are reported 

3) which software components reports a failure and to whom 

4) what information about a failure is saved and how 
Failure recovery may include any of the following: 

1) reloading the DI 

2) restarting the DI without reloading 

3) downgrading part of the hardware resources 

4) removing/replacing a failing hardware component while the DI 
remains on-line 

5) restarting a specific software component, with or without a 
reload 

6) retrying the failing function 

7) executing appropriate on-line diagnostics 

Failure recovery must be preceded by failure isolation and saving of 
relevant information. Isolation of hardware failures is limited to 
identification of the failed card; isolation of software failures is 
limited to identification of the failed software component, where 
software component is defined to be an individually loadable piece of 
software. 
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3.2.5 Failure Management (continued) 

Recovery procedures must take into account the probability of that 
1 failure occurring; for example, if an error is likely to occur very M | 

~* rarely, a reload or restart of the DI may be an acceptable recovery v-r 

procedure. Recovery procedures must also be sensitive to the environment 
in which the failure occurred; for example, recovery procedures for a CIM 
board failure in an NDI may differ, depending on whether or not a back-up 
CIM board exists. 

If the recovery procedure includes a hardware-reset of the total DI, the 
reason for the reset must be saved for use by the on-board diagnostics 
that run as part of the reset process; for example, if part of an SMM 
card is unusable, the on-board diagnostics must not include that part in 
its definition of the DI configuration. 

If a failure is unrecoverable, other DIs connected to the failed DI must 
be able to detect the situation and initiate appropriate recovery action, 
such as operator notification. 

DCN failure management is discussed in more detail in a subsequent 
section of this document. 



b 



■<<y 



O 

/0061y Pa 9 e 3-26 



15 March 1984 

3.3 LAYER SOFTWARE 

The CDNA/tCN layer software provides the functions needed to provide f p 

conmunication between systems, terminals, applications and end users v„y 

connected to the DCN. Since CDNA is based on the ISO's OSI model, its 
layer structure is very similar to the one proposed in the OSI model, but 
includes some enhancements and alterations. 

This section introduces the layer groups and defines some terms that are 
necessary to understand the layers. Subsequent subsections deal with 
each layer group in greater detail. 

The lower layer group is concerned with transmission of data across 
specific network solutions. This group consists of three layers, 
numbered 1, 2, and 3A: 

The Physical layer (1) includes software to activate, maintain and 
deactivate interconnection with various media. 

* Ine Link layer (2) includes software to support synchronization, 
error control and flow control functions for data transfer between 
two or more DIs connected to the same network solution. Layers 1 and 
2 are identical to layers 1 and 2 of the OSI model. 

The Intranet layer (3A ) provides a single network-solution- 
independent interface for users of the lower layers. It is 
responsible for routing and relays within a specific network 
O solution. The layer 3A is a result of the sub-layering of the |*v 

^-^ Network layer of the OSI model. \J? 

The middle layer group provides data-independent, end-to-end services and 
protocols. This group consists of the following: 

The Internet layer (3B) provides a relay function between different 
network solutions to allow users connected to different network 
solutions to exchange information. The layer 3B is a result of the 
sub-layering of OSI layer 3 into Internet (3B) and Intranet (3A) 
layers. 

The Transport layer (4) functions are identical to the OSI layer 4. 
The CDNA/DCN Transport functions are provided by two "sub-layers," 
called Xerox Transport and Generic Transport. 

The X.25 Support layer (4B) provides a service equivalent to that 
provided by an X.25 network. 
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3.3 LAYER SOFTWARE (continued) 

r~\ The higher layer group provides data-dependent, end-to-end services and 

h 1 protocols in direct support of applications. This group provides the 

functionality of the layers identified as Application, Presentation and 
Session layers in the OSI model, although it is not defined as three 
distinct layers. ' 

CDNA/tCN defines a distinct higher layer group for each different type of 
application. In Release 1, the higher layer group provided is the 
Interactive Transfer Service (ITS); ITS supports the OSI Application, 
Presentation and Session layer functions for data transfer between two 
interactive applications and between an application and a terminal. 

A separate higher layer group, Batch Transfer Service (BTS) , will provide 
batch data transfer functions in a subsequent release. 
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3.3 LAYER SOFTWARE (continued) 
LAYERLAND GLOSSARY 

DATA UNIT A "data unit" is data that is transmitted, as a unit, 

between peer entities in different systems; the term is 
usually used synonymously with "protocol data unit (PDU) . " 

RELAY The term "relay" is used to define the process in which a 

CDNA system receives a data unit from one locally connected 
network solution and transmits it on another locally 
connected network solution. 

In the configuration pictured below, there are three CDNA 
systems, labelled A, B, and C, and two network solutions, 
numbered 1 and 2. System A is connected to network 1; 
system C is connected to network 2; and system B is 
connected to both networks 1 and 2. 

+ + 
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+ — + — + 
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Suppose system A wants to send a data unit to system C. 
System A will send it to system B on network solution 1. 
System B will receive it on network solution 1 and will 
determine that it is destined for system C. System B will 
then transmit the data unit on network solution 2. System C 
will receive it on network solution 2. The function 
performed by system B, in this example, is called a relay. 

HOP The term "hop" is associated with the term "relay." In the 
above example, one says that system C is one hop away from 
system A, etc. A hop count is maintained in the Internet 
header of each data unit and is incremented by the Internet 
layer each time a hop is made. Should the hop count ever 
exceed sixteen, the data unit is discarded. This use of the 
hop count is intended to prevent a data unit from wandering 
aimlessly through the DCN forever. 
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3.3 LAYER SOFTWARE (continued) 
,sT~\ LAYERLAND GLOSSARY (continued) |~v 

LOCALLY CONNECTED NETWORK SOLUTION A network solution is said to be 

"locally connected" to a system if that system can 
directly transfer data across that network solution to 
another system on the same network solution. In the 
above example, systems A and C each have one locally 
connected network solution; system B has two locally 
connected network solutions. 

Note that this term has been adopted for this document 
because of the potential confusion between "Distributed 
Communications Network (DCN) " and "directly connected 
network (DCN)." The latter term is used in the CDNA 
GDS which was written before the term "Distributed 
Communications Network" came into being. 



REMOTELY CONNECTED NETWORK SOLUTION A network solution is said to be 

"remotely connected" to a system if that system is not 
locally connected to that network solution, but there 
if N j exists some path whereby that system may transmit data (" 

"Vw to that network solution in one or more hops. 
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3.3 LAYER SOFTWARE (continued) 

C% LAYERLAND GLOSSARY (continued) /""^ 

*' V^ 

INTERFACE METHDDS Software modules within the same system can 

communicate with each other using any of the methods 
described below; software modules in different 
systems can communicate with each other only by use 
of a connection. 

Call/return interface - within the same 
system, one module may "call" the other via the 
call/return interface; only the two modules are 
involved in this form of interface. 

Inter Task Message interface - within the same 
system, a module may communicate with another 
module using the inter-task message interface 
provided by the Executive. 

Connection - if modules reside in different 
systems, they can communicate with each other 
only by establishing a "connection." Depending 
on the expected duration and usage of a 
connection, one of the following connection 
modes is used: 

O Liaison-mode has discrete establishment, _^a 

data transfer, and termination phases and W | 
is used when significant amounts of data ^-^ 
are expected to be sent back and forth 
over some period of time. 

Datagram mode is transaction-oriented; a 
datagram is a single data unit exchanged 
between two entities. There are no 
discrete establishment, data transfer, and 
termination phases; address information is 
included within each datagram. 

Broadcast/multicast mode is an expansion 
of datagram mode in that it permits 
transmission of a datagram to more than 
one entity. 



o o 

/0074y Page 3-31 



15 March 1984 



3.3 LAYER SOFTWARE (continued) 



o 



LAYERLAND GLOSSARY (continued) 



NETWORK ADDRESS 



All externally addressable DCN software is identified 
via a three-part address that provides a unique 
identification within the catenet; a full network 
address consists of the following parts: 



O 



Network ID Each network solution with a catenet 
is assigned a unique 32-bit Network ID. DCN systems 
will use Network IDs assigned by Xerox to ensure 
their being unique worldwide. 

System ID At the time of its manufacture, each 
DI is assigned a unique 48-bit identification number 
from a pool of numbers allocated to Control Data by 
Xerox. This number is written into battery-backed 
RAM and is used throughout the catenet as the System 
ID for that DI. 



^S 



v 



The System ID is used as the Ethernet address for 
any system that is locally connected to one or more 
Ethernet network solutions. 

HDLC station addresses are handled locally by any 
two DIs that are locally connected by an HDLC line; 
the station address is not used as the System ID. 



SAP ID 



A SAP can be viewed as a "port" 



through which two components communicate with each 
other. The SAP ID is a 16-bit number that 
identifies a SAP in such a way that software in the 
local system can access another component by its SAP 
ID. Dedicated ('Veil known") SAP IDs are assigned 
to some frequently used components; other SAP IDs 
are dynamically assigned as needed. 
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3.3.1 Lower Layers 

Ci Lower layer software is concerned with moving data from one system to g^~^ 
another system within a specific network solution. In addition, the \^j 

lower layers are responsible for routing and relaying data units within a 
single network solution. Note that the network solutions to be .supported 
in Release 1 do not need software support to relay or route within a 
network solution and consequently do not perform any routing. Lower 
layer software will be involved in routing in subsequent releases, in 
particular for the CL80 channelnet. 

The following network solutions will be supported in DCN release 1: 

Ethernet 

Point-to-point HDLC line (up to 56Kbps) 

X.25 virtual circuit used to interconnect two DIs 

In subsequent releases, when a C180 mainframe is supported as a CDNA 
system, the channel interfaces between a C180 mainframe and one or more 
DIs will make up another example of a network solution called the 
"channelnet." 

Independent software components exist for layer 1 of each network 
solution. Layers 2 and 3A software includes code that is common to all 
network solutions as well as code specific to each network solution. 

O Layer 1, 2 and 3A software for a given network solution work together to ^^ 
move data between systems connected to that network solution. || 
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3.3.1.1 Layer 1 
,, v ^yer 1 software for Release 1 consists of the follow!^: 
^ ■■-* . ciM controlware 

E9CI controlware 

Controlware resides and executes on ^^ar^to-pport 
physical interconnection with different types 
lines. It consists of three parts: 

interface with layer 2 software 

state program to provide the interface to —cation^ 
lines. Different state P"f agJ£Bt &r£ f ^ Till 

- USTTSgS? sJSSonoSI SSfS^ ^ asynchronous 
terminal lines. 

and from the Ethernet 1S Physically moveaoy ^ 

. controller Intel 82256 * l J' f ^ " ^°Lta between the SMM 

f x ESCI controlware programs this chip tomove oat for the 

and Ethernet transceiver. A set of w^Jg^ JStion of data 
controller chip to inform it about tne pny incoming d ata. 
buffers for outgoing data and empty buffers ror 

B.-.3.-.5: -ssawsssf -X asr - - 
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3.3.1.2 Layer 2 

Layer 2 software includes the following: 



Device Manager (DVM) ^ 

HDLC Stream Service Routine (SSR) 
ESCI Stream Service Routine (SSR) 



+ + . + 

.'HDLC SSRIESCI SSR ! 



i 



+ + + Layer 2 

I Device Manager J 
I ( D V M ) : 

i CIM ! ESCI 'Layer 1 
I Controlware I Controlware 1 

DVM provides a general-purpose interface between layer 1 software on 
intelligent cards (e.g. CIM and ESCI) and the Stream Service Routines 
(SSRs) , which execute on the MPB card. This interface is provided via a 
table called Device Control Block (DOB) 

A separate DCB exists for each intelligent card in the DI. The DCB 

contains : \ 

^"^ a command ring , which contains command packets sent to the layer 1 v/ 

software by the layer 2 software. 

a status ring , which contains status packets sent to the layer 2 
software by the layer 1 software 

two chains of empty buffers , which contain empty buffers to 
receive the incoming data units. Layer 1 software uses one chain 
at a time. When all the buffers in one chain are used up, layer 1 
software starts using the second chain; layer 1 software notifies 
DVM when this occurs, so that DVM can obtain a new buffer chain. 

Layer 1 software communicates with the SSR software by constructing a 
status packet, adding it to the status ring in the DCB, and interrupting 
the MPB card. The interrupt is processed by the DVM, which checks for 
any outstanding status packets. If one is found, it is sent to the SSR 
via an intertask message. 



o 



/0074y Page 3-35 



lb Marcn isc* 



3.3.1.2 Layer 2 (continued) 

SSR software cans '™J~»?££ ^TaS^rl^^S^ ~ 

command (s) sent by the SSR. 

SSPs are responsible for statistics collection and error loggia for 

themselves as well as associated layer 1 software. 

The HDLC SSR provides layer 2 functions for the gJ^J^te^ 
synchronous K DIC ItoJK SSR Jjg—^J^K^ as 
protocol; options tosupport toe ^^£f £f £ c J oss the HDLC 
are those options needed to load a remote u± «-«• exists 

tine. These options can be selected dynamically. HDLC^SSR exists 

network solution. 

As 



The ESCI SSR is not required to support any comjlex Protocol. I 
a" results the ESCI SSR is a relatively simple piece or sortwa 
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3.3.1.3 Layer 3A 

Layer 3A software consist of a single component called Intranet. 
Intranet provides an interface between the other lower layers (1 and 2) 
and a subset of the users of these layers. This subset includes users 
who view layers 1 and 2 as providing an interface to a networV. Intranet 
users, illustrated below, are: 

- Internet layer (3B) 

- Initialization M-E 

- BIP/SVM 






^M^ir 
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INTERNET 



1 INITIALIZATION M-E 
-+ 



-+- 



BIP/SVM 



+ 



N 



N E 



H D L C SSR 



E S C I SSR 



MCI SSR 



+ + 



DEVICE MANAGER 



C I M 
CONTROLWARE 



E S C I 

CONTROLWARE 



-+ 



MCI 
DRIVER 



Intranet provides the following services to its users: 

- open and close a 3A SAP 

- send data requests 

- receive data and broadcast indications 

- notification, to users with an open 3A SAP, of changes in 
the status of underlying network solutions. 

Intranet maintains output queues for the underlying network solutions. 
For each queue, Intranet maintains two thresholds, called congestion and 
uncongestion thresholds; the congestion threshold is higher than the 
uncongestion threshold. If the number of outgoing messages in a queue 
exceeds the congestion threshold, the associated network solution is 
considered "congested." It remains congested until the number of 
messages in the queue becomes less than the uncongestion threshold. Two 
distinct thresholds are maintained to avoid the situation where the 
status of a network solution is continuously changing between conqested 
and uncongested. * 
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3.3.1.4 C170 Channel Support 

<<~\ Release 1 supports a channel interface with a C170 mainframe. Although -^ 

: VJ the C170 mainframe channel interface software cannot be associated with ;|J 

any network solution and is not actually a CDNA lower layer, the DCNS 
implementation is patterned after the lower layer groups discussed m 
this section. 

The "layer 1" software for the C170 mainframe channel interface is called 
the MCI driver. It resides on the SMM card and executes on the MIB 
card. It uses the hardware on the MCI card to move data to and from the 
channel interface. The MCI driver does not use the DVM to interface with 
the MCI "layer 2" software, because both "layers" reside on the same 
card; they can communicate using a direct interface. 

The "layer 2" software for the C170 mainframe channel interface is not 
required to support any complex protocol; as a result, the MCI SSR is a 
relatively simple piece of software. 
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3.3.2 Middle Layers 

The OSI model defines a single middle layer, called the Transport layer 
(4); CDNA/DCN defines the Transport layer to consist of two "sub-layers," 
Generic Transport and Xerox Transport. CDNA/tCN defines two additional 
middle layers: the Internet layer (3B) and the X.25 Support layer. The 
relationship between these middle layer components is illustrated below. 






+ + 

X.25 SUPPORT LAYER 



GENERIC TRANSPORT 



XEROX TRANSPORT 



INTERNET LAYER 
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3.3.2.1 Internet Layer 

<•> different network solutions within toe catenet. In DCN reiea ^ i> 

Internet layer functions are provided via the Xerox Internet prow*. 

^e internet layer provides the following services to users within its 
system: 



Datagram Request 
Datagram Indication 
Broadcast Indication 



in addition, the Internet layer ^ages ^i^aSy'connectSf 
(3A) layer to transmit and receive data units from iocaxj.y <-« 



network solutions. 



The internet layer receives data units from two sources: 

from within the CDNA system in which it resides 

from outside the system across a locally connected network 
solution. 



in either case, if the destination Network ID identifies a locally 
conn^o network solution, tt, ^^stination^stem ID is used to 



•"■'"> Tn either case, it tne Qesumtiu. ^.^..^ ~~ - r: ^ ^ .__ _^ ^ ^- N 



i y connected network solution, Jhe^inrtion^8t« 
Vsi determine if the data is destined for this system. 

If it is, the destination 3B SAP ID is used to determine the 
appropriate software component within this system. 

tf it is not, the data is transmitted across the specified 
locally comectS network solution to the destination system 
specified by the destination System ID. 

Se possible paths in exact proportion to their cost. 
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3.3.2.1 Internet Layer (continued) 

If a path exists, the Internet Routing tables contain the Network f J 

ID/System ID of next "hop," i.e., the next system enroute to the final ^^ 
destination; the Network ID identifies the locally connected network 
solution to be used by the Internet layer to transmit the data unit. 

Each time Internet layer relays a data unit, it increments the cumulative 
hop count in the Internet header of the data unit. If the resultant hop 
count exceeds sixteen, the Internet layer discards the data unit and 
notifies the originator. If the Internet layer cannot re-route or 
deliver a received data unit for any other reason, it discards the data 
unit and notifies the originator. 

The Internet layer relies on the Routing M-E to maintain the Internet 
Routing tables as well as to provide services to open and close Internet 
SAPs. The section on the Routing M-E discusses these services in more 
detail. 
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3.3.2.2 Transport Layer 

The Transport layer is implemented as two software components, or (f~\ 

"sub-layers:" v 

Generic Transport - provides services identical to ;NBS and 

ISO class four Transport. It Uses the 
Xerox Transport to help provide these 
services. Where there is no direct 
mapping between NBS/ISO services and 
Xerox Transport services, it provides 
the functions needed to support this 
mapping. 

Xerox Transport - implements the Xerox sequence packet 

protocol. 

All Release 1 DI -resident users of the Transport layer use the Generic 
Transport services. (Subsequent DCNS releases may include support of 
standards other than Xerox Transport; use of Generic Transport will 
eliminate the need for Transport layer users to be concerned with the 
specification Transport layer standard.) Implementation of Xerox 
Transport does not, however, preclude future applications from using its 
services directly. 

Generic Transport provides the services listed below to its users. 
Additional information on these services appear in the CDNA GDS. 



. SAP management services 

. Connection establishment and disconnect services 

. Data transfer services 

. Expedited data transfer services 

. Status services 

Generic Transport does not limit the maximum data size of data being 
transferred via the Data Transfer services; however, Xerox Transport has 
an upper limit on the maximum data unit size. As a result, Generic 
Transport includes functions to fragment and re-assemble data units as 
necessary; fragmentation and re-assembly is transparent to Generic 
Transport users. 
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3.3.2.2 Transport Layer (continued) 

~> Services provided by Xerox Transport are very similar to those provided 
Ji> } by the Generic Transport. There is a one-to-one match between the 

primitives (interfaces) provided by the two Transports to support the 
services; however, Xerox Transport primitives have the following 
additional features: 

. Each data unit can be assigned. a data stream type. Xerox 
Transport simply passes it on from one user to the other 
(peer) user. 

. Each data unit can be qualified to be or not to be the last 
data unit in a sequence. This feature is used by Generic 
Transport to facilitate its fragmentation and re-assembly of 
data units. 
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3.3.2.3 ^25 Support layer 
*e X.2S Support layer provide^ ^ervice ^valen^o **£?$*» 
"^ S^^Uyfr-a^cS^orol^t^^asse, X.25-speci £ rc C 

characteristics. 

m Release 1, services of the X.25 Support layer are used by the ■ 
following functions: 

o C170 Transform for Transparent A-A connections between DCN 

and C170 Network Products 
o X 25 Transform between DCN and X.25 network 

network. 

The X.25 Support layer provides the follow^ services to its users: 

„. anag^nt services allow auser to operand close »,]£«££ 

SSS.'SSy 1 SS^SoSS*^ these services. 

r ^^^n^r ks^.ss£s^**^« «■ , 

\L_/ of three possible flags: v^ 

- The Q flag, corresponds to the qualifier bit in the X.25 
packet header. 

- Tne D flag corresponds to the delivery confirmation bit in 
"the X.25 packet header. 

- The M flag, corresponds to the "more data" bit in the X.25 
packet header. 

requests. 

i. -^ i«iviaii7e the connection. All queued 
BSStJSS^ %*£ J" S STSSSSnl: discarded oy the two 
peer X.25 Support layer entities. 

SHS^-^^P '^unUsUeTor^e fnc^cTta'units. 

a change the maximum data unit size tot 
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3.3.3 Higher Layers 

Ch lhe hi 9 her lavers Provides data-dependent, end-to-end services and f> 
t> protocols to allow applications to communicate with other applications or V_> 

with terminals. 

* " 

DCNS higher layer services are implemented as a dual-endpoint liaison 
connection service. The end users at the endpoints of the connection are 
viewed as "associates." The connection is called an "association." 
Conceptually, an association may be viewed as a logical connection 
between two peer associates. 

DCNS implements the OSI higher layers as "layer groups." Consolidating 
the layer 5-7 functions into groups is necessary since industry standards 
for individual layers are not complete and agreement has not been reached 
as to how the higher layer functions are to be distributed. Although the 
provided services and protocols of each DCNS layer group are not directly 
mappable to OSI layers 5-7, they do provide functions needed to allow 
communication between user/application processes. 

DCNS will initially provide two higher layer groups: 

Interactive Transfer Service (ITS) - provided in Release 1 

Batch Transfer Service (BTS) - provided in subsequent release (s) 

ITS is the only higher layer group available in the initial release of 

ODCN. ITS provides the set of services required for communication between #Sfc 
two DCN end-users engaged in the transfer of interactive data. The two 1 f 
end-users may both be applications (A-A) or one may be an application and 
the other a terminal user (T-A) . 

Full implementation of ITS will be phased, with early releases of DCN 
focusing on ITS support of Terminal-to-Application (T-A) communication. 
The initial ITS implementation specifically addresses the requirements of 
asynchronous terminal communication with C170 applications. 

The diagram below illustrates DCNS components involved in support of 
asynchronous terminal access to a C170 host. 
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3#3# 3 Higher Layers (continued) 
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»e CHO Int-ae, :ive Virtual Ter^l £* /SS^**^ 
be transformed to the ITS re P res ! n ^rrL 7 . h - .. T . A interactive 
S^-**? ^teractfve^foL^s^hem protocol on to 
Transform. The_ T a ^ era £^ interactive Transform xs not a layer 

%> rs^^n^hSe^lf toVoSoe a «. o^lete picture of the 
Release 1 higher layer group. 

One additional component must be men tioned «* **£ *J Jjjj* 
Support Software, which is also not a ^^™™rSS defined 
Software is the DCN ^^f ^ J^S^ relSse'lK associations 
Terminal Access Process. In ^.£f ^J££ software in a TDI and the 
(connections) exist between Terminal s "PP? r t so ™re software 

C170 Interactive Transform in an MDI, with the Terminal d t*~ 
being the initiator of the association. 

management and windowing. 

*e TC -lnal Support Software uses a set ^t^ansfor^ 

tertrrfo^^un^tiS fre 22 STSE-trlc- for this 

reason. 
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3.3.3 Higher Layers (continued) 

The Terminal Support Software uses the ITS asymmetric service for the 
following functions: 

- Establish an ITS association ; - 

- Transmit Edited terminal input text 

- Transmit Transparent terminal input text 

- Transmit notification of terminal break 

- Transmit one character of terminal interrupt data 

- Transmit notification and values of changed terminal 
attributes 

- Transmit a response to a request for the current values of 
terminal attributes 

- Terminate an ITS association 

The C170 Interactive Transform uses the ITS asymmetric service for the 
following functions: 

- Respond to a request to establish an ITS association -^\ 
^J> - Transmit Formatted terminal output text V-/ 

- Transmit Transparent terminal output text 

- Transmit request to discard queued terminal output data 

- Transmit request for current terminal attributes values 

- Transmit request to change terminal attributes values 

- Terminate an ITS association 



O 
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3.4 NETWORK MANAGEMENT 

> Network managed consists of ^J^^^*^*!*^™ 

J required to manage the Distributed ™J£££Sntlties (M-Es) . M-Es 

mSagement ^^l^^^l^t^ot^^rtl Data Network 

are defined in ^e 0>NA GDS as par tot ^ ^ Dls> 

Architecture (CDNA) . M-E software is axway* y 

Kanagement^ntities provide the following functions: 



\ 



o 
o 



Creation and management of Internet Routing Tables 
Title definition and translation 



o Command processing 

o Dogging 

O File access 

o Error processing 

o Echo processing 



Sach function in this ^^ ^^^ 

SS^M Pgffg ^JS^USSS' *?" 
division is necessitated by the ac t that it£ functions i„ each DI. 

impractical) to support the *f ^/^gg^concerned with direct or 

For example, a sub-function of file access is ^ access tQ 

indirect access to some sort of ^f^gVsupport this 

mass storage ^.therefore wil^no^^le t^» ocessing pr0 vides 

sub-function. Similarly, a sub-f unction user or an 

an interface to a c«nd «u« J such aa ^^ ^ appUcatlons , 

^TnoV^^ in each DI - 

me Com^ M-E, Log M-E a^m^cess M-E have explicit-^ 
stand-alone dependent and indepe ^ P£« ^ softwar e implementing 
implemented in a separate piece of . so£ 2 ar *; t in every D I. The 
SS dependent part of these M-Es will ^ present ^ ^ ^ some of ^ 
S of twaj implementi ^-^fitve ES deepen? a»d independent 
£arts of a given Management-entity. 
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3.4.1 Routing M-E 

The Routing M-E is responsible for creation, update and management of the ( 
tables needed to route information between CDNA systems. The Routing M-E also 
provides the services necessary to open and close 3B SAPs. 

Routing involves finding a path from one system to another, using this path to 
transfer data between the two systems, and locating the software that is to 
receive the data within the destination system. The routing process starts 
when layer 3B software is requested to send a data unit to another system. 
This request includes the network address of the destination system (Network 
ID and System ID) as well as the 3B SAP ID of the destination software. The 
routing process consists of the following sub processes: 



'\ 



Inter-network routing - 



responsible for ensuring that the data unit 
reaches the network solution whose Network ID 
is the same as that of the destination 
system. This is done by delivering the data 
unit to any system that is locally connected 
to the desired network solution. 



Intra-network routing - 



o 



takes over once the data unit reaches a system 

connected to the destination network 

solution. It is concerned with delivering the 

data unit to appropriate system on the 

destination network solution. The System ID 

in the destination address is used to locate /"""V 

the desired system. v./ 



Intra-system routing - 



responsible for delivery of the data unit to 
the appropriate software component once the 
data unit reaches the addressed system. The 
3B SAP ID is used to accomplish this routing. 
Each of these three types of routing is 
described next in more detail. 
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3 4 11 inter -network Routing 

3 In ter-network routing is the most «^^ ta *^ l St? , SS t ^2rk Q 
requires each CDNA system to know the n *f a ™ P c ™ ene \ configuration, the 
solution in the catenet. Po ^unately^ in ^catenet^^ ^ nJBbet of 
number of network solutions will be consiaerao y 

systems. 

..,-. These tables are created 
Each CDNA system contains Internet ^%*J*£& ^ated. The process to 

tables'* section. 

Xnternet routing tahies >« . -» ,*£» » * ^f "c^^eoM" " 
tCR-DS for short; the ^"^"^ilt as "oS in the ICR-DS; each row 

^ainslnrT ^^ as a 

SSTSSf STu rro^rentrv for each path. 

« us consider the «X^««XFZ££ S"^- 
&£.?££- Snfsirf^tf repres^net^r, solutions, n^ers rn 

parentheses represent cost. + + 

P* 1 (5) + + 2 lill . C ! 



r 



^y 



+. i B . - +_-+--+ 

•4 do) ; 8 (i) 

+.4.-+ 6 (5) +-+-^ 
+-+-t \ D • I F ! 



:5 (io) 



3 (7) 



-• E !- 
+ + 



7 (10) 



\ 



Ut us assume that we are looKin, at routing **-*£$£ ffi5 F *» 

solution 8. 

Path-1 A-1-B-2-C-8 
Path-2 A-1-B-4-D-6-F-8 
Sth-3 A-1-B-4-D-5-E-7-F-8 

Path-5 A-3-E-7-F-8 
Path-6 A-3-E-5-D-6-F-8 
Path-7 A-3-E-5-D-4-B-2-C-8 

Son* of these paths will show up in the U*-OS row associated with net^rK 
solution 8. 
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_^ 3.4.1.1 Inter -network Itouting (continued) ^ 

tte first criterion for the paths in the LCR-DS row is that they should not be - y 
overlapping; two paths are said to be overlapping if they start out on the 
same network solutions. In the above list, paths 1 through 3" start out on 
network solution 1; therefore they overlap with each other and so only one of 
these will end up in the LCR-DS row for network solution 8. Similarly, only 
one path out of paths 5 through 7 will find its way to the LCR-DS row. 

Ihe second criterion for a path to be included in the LCR-DS is that, of the 
overlapping paths, the one with the "least cost" will be selected. Ebr 
Release 1, the cost of a network solution is inversely proportional to its 
accessible (static) bandwidth. The cost of a path will be the sum of costs of 
all network solutions that make up the path. A cost of "1" for a network 
solution with bandwidth of 100 megabits per second is used to normalize the 
cost of various network solutions. This normalization yields the following 
cost for some typical bandwidths: 

Bandwidth post 

10 Mbs A (16) 

1.54 Mbs 41(16) 

56 Kbs 6FA(16) 

9.6 Kbs 28BO(16) 

In the sample configuration, the numbers in parenthesis show the cost of each 
network, using these numbers, one gets the following costs for the listed 

o "*■' o 

Path Cost ^^ 

1 -25— 

2 20 

3 35 

5 17 

6 22 

7 47 

Since only one of paths 1 through 3 is to be selected, path number 2 will 
qualify. Similarly, of paths 5 through 7, path number 5 will be selected. 
Paths 2 and 5 will be included in the LCR-DS row according to their increasing 
cost. Therefore, path number 5 will be the first path and path number 2 will 
be the second path in the LCR-DS row. 

However, only limited information about the two selected paths is included in 
the LCR-DS. The following table shows the information included in the LCR-DS 
for these paths: 

POST FIRST NETWORK SOLUTION FIRST RELAY SYSTEM 

(Path 5) 17 3 E 

(Path 2) 20 1 B 

o o 
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3 4 11 inter-network Pouting (continued) 

only the following information: . 

o Existence/non-existence of a path 

,~ * «.>,<=, firctt network solution and 
o Network ID and System ID of the f itst netwo 
system in the path; the next hop 

o Cost of the total path 

e «-v,o r»th in the above example, 
mis allows dynamic and adaptive ^f*£*£%£ ^the' best possible path, 
3nen a data unit leaves system A, ^tarts*^ o r 3 to system 
£ased on current information. It will travel ^ fcQ lt to lts 
E in system E, the best path will be^ selectee o^ ~*^^ solutlon 7 
final destination. ^^^'^ihSf built-in intelligence to react to 

^'£W^£^ «* as failure or con3estlon 

solution 7. , 

B, ere U one more restriction on PathsconsM^ nops^tZtlcally 
S^Ss" Any path that involves tnore than sateen nop atlve hop roun t 

£& ^Internet ^^WJ^S^S the data unit is awarded, 
tts P^evenS e^les "efayi^o? a data unit in the catenet. 



'VV J 
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3.4.1.2 Intra-network Routing 

Intra-network routing is concerned with routing of a data unit within a KJ 
network solution. In Release 1, intra-network routing by the software is not 
needed, so this concept will be illustrated by using the channelnet network 
solution that will be supported in a subsequent release. 

Intra-network routing is initiated when a data unit reaches a system that is 
locally connected to the destination network solution. Let us use the 
following configuration as an example to illustrate the intra-network routing. 



o 



/ 



/ 



C180 
MAINFRAME 
A 




_y L 

/ / 




-/ 



Suppose the C180 mainframe is sending a data unit to TDI-E. The address of 
this TDI will be stated to be Network ID=3/System ID=E. When this data unit 
reachs MDI-C, the MDI-C 3B software will do the following: 

a) It will check the destination Network ID of the data unit and 
find it to be 3. 

b) It will check its LCR-DS to see if network 3 is accessible. 

c) It will find that this network is accessible and is locally 
connected. 

d) It will compare the destination System ID (E) with its own System 
ID (C) and find that they differ. 

e) It will transmit across network solution 3 and address it for 
system E. 

f) TDI-E will repeat steps a through d and accept the data unit. 



O 
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3 4 l 2 intra-network Pouting (continued) 

O ^ conflation shows two ™S£££°J^ *™^ f O 

ch^nel connections; both channel c0 ™f ^ ^ of the channel connections to 
gSTof a sirflle. network sol^ion ; All^rsome s 0^ ie ^^ on> 

the same C180 mainframe may be conrigurea 

v * r and C are all connected to the same 
in the above configuration, syst ^ *; *'J^ red 1# now let us assume that 
Stwork solution, namely the <*^J" e !j2!m c The destination address of 
#£ > wants to send ^ ™^^*&t- ID-C *• **■«* 
fte^delcSb. S'iXrSSS* routir* processing: ^ ^ ^ 

a) The internet (3B) software in system Bwill use it. ^;^ y t0 
£££.*£ w- flsSrrmine^fthe data is not destined 
for itself. 
M n. internet (3B, software will trans.it the date unit to the 
system A. 

- sr h wja?^*? Intranet ,3A) 

^ oeltinationlyetem is other than System A. 

V e, *e channelnet Intranet software will relay the data unit to 

system C. 
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3.4.1.3 Intra-system Routing 

r% Intrasystem routing is concerned with delivering the received data unit to thvO 

^ appropriate software conponent within the system. The Internet (3B) software 
maintains a table of 3B SAP IDs of all software components that either have 
opened 3B SAPs or have a dedicated SAP. This table also contains the current 
status of the SAP (i.e. open or closed) as well as the address of a procedure 
to be called to deliver the incoming data units. 

After verifying that the Network ID and System ID of the received data unit 
are the same as that of the system where the data unit is received, the 
Internet (3B) software uses the 3B SAP in the address part of the received 
data unit to find a matching entry in its 3B SAP table. If the entry is found 
and the SAP is open, the received data unit is delivered to the associated 
software component. Otherwise, the data unit is discarded and an error PDU is 
sent to the source of the data unit. 



O 



o 
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3 4 1.4 Generation of Pouting Tables 

4 

3B SAP table 

- local Directly Connected Network Solution Data Store 
(L-DCN-DS) 

- Remote Directly Connected Network Solution Data Store 
(R-DCN-DS) 

- local Network/Community Title - Address Table 

- Ranote Network/Cor^nunity Title - Address Table 

- Least Cost Pouting Data Store (I£R-DS) 

.^SAPtable contains inf option £out «^» ^S^iT 
Sl^rS a^furSefde^ription. 1. table » used 
for the intrasystem routing. 

tt. „»» contains infection about all locally connected network 
yf~"\ solutions. ^--\ 

M *e R-DCN-DS contains information atcut ail redely connected network 

solutions. 

^ ,^ ^.t^tyO—mltY ^^^Jt^-g^iUes-^icrge ° 
^ny^^^^SefafdJS via conflation co^ands. 

Th^t^t^k/^^ ^SSSZ£ 

F^otely connected network ^f^^ion is received in Routing 
SSS3S datTSnitfS r»i-^ systems. 

The LCR-DS is a sinple table and *•"*£?£?£ eSSt^SrSSSKNfi? 
Stra-ne wrk routing. "^i'.^STdSuStoo provides a simple overview 
Sbl. is rather complex. *e • following ^^^^ £or rigoto us details, 
of this process; the reader is rererreo <. 
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3.4.1.4 Generation of Routing Tables (continued) 

f"J) The LCR-DS contains information about least cost paths to accessible network {"") 
solutions. Even though this table does not contain information about every ^^^ 
possible path, the process used to create and update this table has to know 
these paths completely in order to select the least cost non-KJver lapping paths. 

Information about different paths can be either pre-defined or computed 
dynamically. In CDNA this information is not pre-defined? instead it is 
dynamically computed and updated periodically. 

Any path definition has to be based on configuration information of individual 
CDNA systems that make up the path. However, no single system can compute 
these paths based on its own configuration information (trivial paths being 
exceptions) . Therefore, any system or process interested in computing such 
paths must obtain up-to-date configuration information from other systems if 
tables are to be maintained dynamically. Fortunately, configuration 
information is needed from a relatively small number of systems. 

For example, consider the following configuration, which includes four DIs 
connected to a single network solution, namely Ethernet. 

+ + + + 

+ + + + + + 

i c i : d • 
+ + + + 

Let us assume we are trying to build the LCR-DS in system A. This 
configuration contains only one network solution that is locally connected to 
system A. Systems B, C, and D cannot provide any new information to system A 
to help it build its LCR-DS. In this case, the LCR-DS will contain a single 
row that is associated with the locally connected network solution. 



o 



o 
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. 3.4.1.4 Generation of luting Tfcbles (continued) 

i Next, let us look at a more complex configuration. O 



+ + 

! A 1 

+ — + — + 



y 



r 



+ — + — + 

: b : 

+ — + — + 

/-. — '- — l ?/ 

+ — + — + 
: c : 
+ + 

once again, let us try to build the «£»£**£& S£JSTS«- * * 
solutions numbered 1 and 2 "\"»F2S*i«2 fj remotely connected to it. 
itself cannot find out that network solution 2 is <^ ^^^ t0 both 

accessible to it. 

*. points being made by the above examples «y be s^ed up as follows: 

• ssss-^-s ss?rsr j^r csr^t 

network solutions locally connected to them. 



^ 



; 



^ta^uJ^ 
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3.4.1.4 Generation of Routing Tables (continued) 

If a system is locally connected to more than one network solution, the C 
Routing M-E periodically broadcasts Routing Information PDUs (RI-PDUs) on 
all its locally connected network solutions. The RI-FDU contains 
information about locally connected networks as well as local network and 
community titles. Normally, an RI-PDU is sent once every thirty seconds, 
but will be sent sooner if a change takes place in the information 
included in the RI-FDU. 

Each RI-FDU contains a sequence number and a change/no change flag. Each 
time an RI-PDU is transmitted, its sequence number is incremented by one 
and all changed information is flagged. 

The Routing M-E in each system, receives RI-PDUs from other systems. The 
sequence number of the received RI-FDU is checked. If the sequence 
number is the same as one received previously from the same system, it is 
discarded. Otherwise, the following is done: 

A copy is made and saved for local processing. 

The RI-FDU is broadcasted on all locally connected 
network solutions, except the one on which it was 
received. 

The local copy is examined for change flag(s) . If 

O there are no changes, the processing ends. Otherwise, 

the changed information is used to update the £% 

corresponding information in the R-DCN-DS and remote %r 
network/community title-address table. 

If there were any changes in the R-DCN-DS entries, the 
LCR-DS is re-computed and updated. 



o 
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3 4 14 Generation of Routing Tables (continued) 

^ „ Release 1 system connected to more ^™*»2Z3*^ °^ Q 

> NDIs. Each NDI sends information about its »»£* of connected network AJ 
SlStions via Routing Information PDUs. As e ^ a £S-DS is recomputed to 
solutions in the L-DCN-DS or MM C ^s t ep-by-step process used to ere, 



a) 



f 



the LCR-DS is as follows: 

Cteate the Lo-1 «^ , <*^^J£X B 2S-rSl 

Maintain the «ceived OitectlY electee **£ j***^ Bt ° t * 
(R-DCN-DS) , which contains an ent^J ot g£ n =* try wiU contain 
SoStra^^eSol.^intTo^a^connStaa to the syste. 

associated with that entry. 

Since ail locally connected *g?^»£g££Z£%S§L 
reachable, create a row for each J^£ ^"V 
in STlCR-DS (i.e., internet routing table.) 

«« each locally connected network ^^^T^eoT^e 
the R-DCN-DS entries to see if its NetworK £ If a 

locally connected network solutions in thjJRDQN ^^ ^.^ 
match is found, then all other locally c ^ ^^ ^ 
in that entry will also teteaaan* rr a ^ 
LCR-DS is being created. Therefore, aaa tnes lcr-ds, 

connected network solutions (i.e. f***™^^ present and 
if they are not already present . Iftt-tf* r^ *g J/ present in 
the newly discovered path does not overlap discovered 

the LCR-DS row, add this path to therw ±i &nd retain 
path overlaps one already present, compare the two c 
the lower cost path in the row. 

a fho Tn*-ns will contain rows for remotely 
e , As a result of step }r «» ICR«^ ^ °° these rowS , e tc. 
connected network solutions. Repeat step a 



c) 



d) 



f 
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3.4.1.5 Open Issues on CDNA Routing 

The following is a list of limitations and problems with CDNA routing as 
described in the CDNA GDS. Some of these limitations are inherent to the 
chosen philosophy for routing. Others are problems or holes Which need to be 
addressed. 

a) The algorithm used to compute the cost of a path does not take into 
account the overhead involved in relaying a data unit from one 
network solution to another. This is the CPU overhead in the system 
doing the relay. This cost should be easy to compute and include in 
the total cost. 

b ) The inpact of congestion on the cost associated with a specific 
network solution is not adequately addressed. 

°) The routing tables do not contain any information about the status 
of systems which are connected to one network solution only. For 
example in the following configuration, system A has no way of 
finding if system B is up or down. The best it can do is to detect 
the absence of system B via time out mechanisms in Transport layer 
software. This limitation is inherent in the approach chosen for 
the CDNA routing, but is not serious. 
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3.4.2 Directory M-E 

A Directory M-E is resident in every DI. Each ^^JjL^f?^? 
maintains local data stores that contain Title information that is most 
beneficial to its local system and the catenet as a whole. _ Collectively, 
tSoiSStor? M-Es maintain a distributed Directory of Titles and 
associated Addresses. 

Directory M-Es use Internet datagram and broadcast services to^ ^H^of* 
Title information to Directory M-Es in other systems. Dissemination of 
Sis informTtion is conducted under the control of the Directory M-E 
protocol, which allows Directory M-Es to c ^^ c ?f ™ * ™7 
minimizes the amount of network traffic required to ™intain a 
destributed Directory and provides Directory services at a high 
performance level. 

Directory M-E services fall into two categories: 



Registration services 



Translation services 



Software components use Registration 
services to announce availability, 
location, and specific characteristics of 
services they offer. During 
initialization, each component determines 
its own network address and uses 
Registration services to announce its 
availability to other components at the 
location specified by its network 
address. Registration services are also 
provided to alter and delete entries from 
the Directory. 

Software components use Translation 
services to determine the network location 
of a required or requested service. 
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3.4.2.1 Directory Entries 

^-^ The Directory consists of multiple Directory Entries, each of which \^j 

contains a registered Title/Address pair. A Title/Address pair consists 
of the following information: t 

Title - any string of 1 to 256 ASCII (Parity Bit = 0) 
characters. 

Address - a field of octets that contains one of the following: 

A network address that consists of: 

3B Network ID, or 

3B Network ID + 3B System ID, or 

3B Network ID + 3B System ID + 3B SAP ID 

3B Network ID + 3B System ID + 3B SAP ID + 4 SAP ID 

A non-network address that is a 32-bit machine-address 
field used by components within a system to exchange 
interface addresses. Non-network addresses have only 
local system significance and therefore Directory 
information relative to non-network addresses is not 
distributed throughout the network. 

Each Directory Entry also contains a Directory Entry Identifier that 

O uniquely identifies when and where that entry was created or last „ 

updated. Whenever a Directory Entry is changed in any fashion, its f* 

Directory Entry Identifier is also changed. The Directory Entry ^^ 

Identifier is an 18-octet value comprised of the local Network ID / 
System ID and date/time stamps. 

A Directory Entry may optionally contain attributes that can be used in 
the following ways: 

specify additional Title-matching criteria that must be met 
before that Directory Entry will be considered to be a match in 
a request for translation; 

indicate a priority relative to other entries with the same 
Title; 

identify protocol (s) associated with that Directory Entry. 



o o 
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•"> 3.4.2.1 Directory Entries (continued) 

^ I -™i« over domains in which a registered (JJI 

^ Tne Directory user has some cor ^^Sg^** a.m.- 
Title is meaningful, via tne u"c 

Title Domain, " ^.^T*^^^^^ * 
some insight to ^ »|^* £Jt£d Title Domain specifies a 
specific Title should be distributee. *"£ t t from whence most 

SSet of networks and ^^re^StS wi£ ^probably originate, 
of the requests for the registered titl«wux P know ledge 

specified domain. 

translation of a Title can be obtained from i£les a ,*«<* 
Title Domain, if the Translation a ^^~^ it ^ Ti ti» Domain. 
EOTain that includes some portion of the specified 

Tne follow^ special Titles are used to specify detain parameters: 

, ar - fixx" i S a 1-32 octet community 
- -Community xx" wnere cQmunity titles are registered 

as the result of configuration 

commands. ^- ^ 



c 



„!,.„ » rr » is the hex number of 3B 
. "Broadcast Network rr" where rr is ^ nmtet Qf hops) to 

the remote network; the Routing M-E 
registers one such Title for each 
iSuy Connected network solution 
(W hops away) , one such Title for 
each network solution that is 01 

hops away, and so forth. 

~* hi/ nirectorv users when they want to 
These special Titles are ^^"^e^belonging to community xx" or 
specifyVdomain in terms of "all ^f Sal network." When the Directory 
Sll networks within "hops from **££*£&!* by one of the above 
M-E receives a request^ ^^gtory ^or that Title in order to 
^^SfS^ToSS^ni - the specified donam. 
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3.4.2.2 Registration Services 

J Registration services include primitives to; \_J 

register a Title, its corresponding Address, and other optional 
information in the Directory 

change information about a Title previously registered 

delete a Title from the Directory 

Create Entry Primitive 

A Directory user utilizes the Create Entry primitive to request that a 
new Directory Entry be created. Parameters are: 

Title - specifies the ASCII Title, as defined above. 

Address - specifies the Address to be associated with the Title 
in the Directory Entry. The user may specify the 
Address in any of the ways defined above, or, may 
specify only the 3B SAP ID or the 3B SAP ID + the 4 
SAP ID. If only SAP ID(s) are specified or if no 
Address parameter is given at all, the Directory M-E 
supplies the Network ID / System ID of the local 
system. 

yj Directly Accessible Service - optionally specifies the set of CDNA W% 

end-to-end protocols associated with this Directory ^ ti ^ 
Entry. This parameter can be used to ensure that the 
two potentially communicating end-users have 
compatible underlying services. This attribute is 
used as a Title-matching criterion only if it is 
specified on a Translation request, in which case 
only Titles registered with the same "directly 
accessible service" will be supplied in response. 

Password - optional parameter that can be used as an extra 
measure of security, if this attribute is 
registered, it is always used as a Title-matching 
criterion; i.e., subsequent Translation requests must 
contain a matching password. 

User Information - optional parameter that can be used to pass up 
to 32 octets of information in responses to 
subsequent Translation requests. This parameter is 
not used as a Title-matching criterion. 
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■ 3.4.2.2 registration Services (continued) 

J Create ft* ™ Primitive (continued) i> 

Title Domain - optional F-^er f at can be «g g^^SSt 
domain over which ™?J*;; e of the following: 
Domain may be specified as one or « 

(default value) 
local System < aetau 

Local Network 

Broadcast Network rr 

Community "xx" 

Catenet 

rifles when and where to distribute the 
Distribution "JXSi^SSSJf with this Directory Entry: 

distribute, upon request, only to the 
requesting Directory M-E 

diStr SS'D^ecto^MS'aS Si Directory 
JSTS^ — neUk (default value) 

distribute, upon request, to the 
requesting Directory M-E and axi_ui 
M-Es on the same network and also 
, ^ ^erioSically distribute throughout the p 

M Stle Domain. The frequency of Ky 

distribution is configurable. 

Priority - specifies ^^g^^^^A* 
Directory Entry. The range « v default 

is - 3, with 3 ^^^^XfexSt for the same 

IfnotlsS asTScS^atchin, criterion. 

^ i« irni-rv reouest by creating an entry 

Seated* Srs in the local system. 

tte Dir ec r « «~ -s^g^riM " Y 

S^eftof^n c^Stfon process!,,. 

- ^ifies a Title Domain other than "local 
If the Create Entry request ^^ e * * ™ncv, the Directory M-E sends a 



Domain. 
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3. 4. 2. 2 Registration Services (continued) 
Change Entry Primitive \_y 

12fJ2°? US ! r utilizes the <***« Entry primitive to requlst that a 
specific Directory Entry be altered. The user must identify the tarcet 
entry by supplying the Directory Entry Identifier. The user ell chaSe 
any of the Create Entry values except the Title parameter. ^ 

2^^^'^ prOC ?f Ses a <*«*• »*iy primitive in the same manner 
ent?v S SvS^ pri T 1,:1 Y e ' Tl Cept that instead of creating a new RDS 
entry, an existing entry is updated. A new Directory Entry Identifier is 
generated and returned to the requestor. laencirier is 

Distribution, if any, of the altered entry is done according to the same 
rules used for the Change Entry primitive. *a=oiaing to tne same 



Delete Entry Primitive 

A directory user utilizes the Delete Entry primitive to request that the 
a Directory Entry be deleted, in order to delete a Directory Entry", Si 
user must specify both the Title and Directory Entry Identifier 

OfrSm^hfp^ "^ ll 00 ^ 5 a ****** atr y re< ^ est h y removing the entry *\ 
from the RDS. If the Title Domain of the deleted entry is not "Local O 

KnSc^n^ Distribution Frequency is registered, the Directory ' 
M-E notifies all networks identified by the Title Domain that the 
Directory Entry has been deleted. 
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3.4.2.3 Translation Services 

Translation services include primitives for: Q 

requesting a Title Translation, . 

notification that a Translation has been found, 

requesting that a previously requested Translation be 

cancelled, 

notification that a Translation request has been 

terminated. 

Processing of Translation ^^^^^^TSTpS^ that 
inter-network conntunication between D^ory Translation 

a single Translation request will resul t^iv «£^ lation indiC ations may 
indications. For these ;fj n '^ t o a Translation request. 

issr cress? zsfi^&rsz ^^ 

^^T^^° n > 'SSSSS M^ that can be used to 
^tcn^fts^tndications. 

Translation Bequest Primitive 

A Directory user utilizes the , , cor responding <-« >-"- 

of this primitive are as follows: 

wtle . specifies the 1 - 256 character «t£*Jg-J*-. 
B ThTfull Title c^Xi canbe used to locate 

S33S5SS1SS St ■» < elatea in - 

way: 

? - represents any single character 

* represents any string of characters 
of arbitrary length 

[ ] represents any single character that 
is: 

a member of the set enclosed in 
square brackets (e.g., tabqz ] 
means "a" or "b" or "q M or z ) 

within a range (e.g., 10-91) 
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V> A Directory user utilizes the Translation »gggffi£& ™*~ 

that thejrectory « ^^^Tt^mitchingTriteria. Tne parame* 
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3.4.2.3 Translation Services (continued) 
Translation Request Primitive (continued) 

Out-of-date Identifier - specifies a Directory Entry Identifier 
that the user previously obtained in a Translation 
indication; the Address associated with that 
Identifier could not be used to reach the destination 
service. If an Out-of-date Identifier is specified, 
the Directory M-E does not consider that Directory 
Entry to be a match for the Translation request, up 
to eight Out-of-date Identifiers may be specified on 
a single Translation request. 

Directly Accessible Service - optional parameter that specifies the 
set of CDNA end-to-end protocols that are to be 
associated with any matching entries. This parameter 
can be used to ensure that the two potentially 
communicating end-users have compatible underlying 
services. 

Password - provides a measure of Directory Entry security. If 
specified on a Translation request, a matched 
Directory Entry must have the same value, if not 
specified on a Translation request, a matched entry 
must not contain a password. 

\J Search Duration - optional parameter that specifies the maximum %l 

amount of time that the Directory M-E is to search 
for the requested Translation. Minimum, maximum, and 
default time values are configurable. 

Search Domain - specifies the domain across which a search for the 
Title is to be made. A Search Domain may be 
specified as one of the following: 

local System (default value) 

Local Network 

Broadcast Network "rr" 

Community "xx" 

Catenet 
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3 4.2.3 Translation Services (continued) 

one. * 

If the Search Domain is not "local System," the value 
restricted to the range 1-8. 

If the Search Domain is "Local System," the value can be in 
the range 1 - 255. 

translations. 

The Directory M-E Processes a Tr-uaon g^ J* %i£H» t 
its Translation Bequest Data ""•"^B^orf im notifies the user that 
r^es t'TSfani rt £"S£*Y « is now searchrng for the 
requested Title Translation. 

system search: 

a selss -e^trf ^Tsasrss srasr 

components. 

*. other data store is * jM Ration -t^o^^.^The TDS 
contains entries for Title ^f^™ 3 X |n tr ies in the TDS are 
received Directory P^^^i^Sied for a Title registered 
directly related, to the Title ™™J^ C g«d at one-hundred 
in^^oSst XrST™ Sellout when maximum sxze » 



entries; 
reached. 



£«tor^^^^^ 
other systems. 

V^ever a etching Title *££••%£?£ ^f oftranlutions 
ST^SSSSAS-SS J &-. J;-,*"- --. entry 
nleUtra^r^anrtion^uel^iStion is sent to the 
originator of the Translation request. 



X. . .---' 



^ 



/0060y *** 3 " 7 ° 



Abort Translation Primitive 

This primitive provides the Directory user with capability to cancel a 
previously issued Translation request. 

Translation Request Termination 

This primitive is used by the Directory M-E to notify the Directory user 
that processing relative to a specific Translation request has terminated. 
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3.4.2.3 Translation Services (continued) 

Translation Indication Primitive 

The Translation indication primitive is used by the Directory to inform 
the Directory user that a Title Translation has been found for a 
previously issued Translation request. The parameters of this primitive 
are as follows: 

Title " The Title contained in the matched Directory 

Entry. 

Address - The Address associated with the matched 

Directory Entry. 

Directory Entry Identifier - The identifier of the matched 

Directory Entry. 

Directly accessible Service - The Directly Accessible Service 

attribute of the matched Directory Entry. 

User Information - The User Information contained in the matched 

Directory Entry. 

Priority - The priority associated with the matched 
_ Directory Entry. 

O 
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34 3 Cgngnand M-E and Cmrend Processors 

O • IZIII design; information will be supplied in a Q 

yJ que Command M-E is undergoing design, uu. ^ 

future update to this docunent. 
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3.4.4 Log M-E 

The Log Management-entity is responsible for providing a service to all C 
DI -resident software to generate log messages and ensure that they are *~ 
written to mass storage for subsequent analysis. In Release 1, the 
physical writing of the log messages to mass storage is handled by a C170 
mainframe program called the C170 Log Server, which is described later in 
this document. 

The Log M-E also allows one or more network operators to receive a 
defined set of log messages as alarms at their consoles. 

The following are examples of types of information that may be logged. 

Resource utilization and error statistics 
Hardware and software failures 
Configuration changes 
Accounting information 

The type of log analysis to be done can vary, based on the needs of 
different sites; so rather than qualify each log message by its 
attributes (such as error statistics message, software failure message, 
etc.), CDNA does not call for any qualification of the log messages. 
Instead, a unique message number is associated with each potential log 
message. (Xialification of log messages is left to analysis software, 
such as the Network Performance Analyzer. 

CDNA defines a concept called "Log Groups." A Log Group contains a list & 
of log message numbers and identifies the destination for these 
messages. A set of Log Groups is associated with each system that can 
generate log messages. Information in the Log Groups is used to control 
the generation and transmission of log messages. 

The Log M-E is implemented as two parts: 

Dependent Log M-E 
Independent Log M-E 

A Dependent Log M-E exists in each DCN system. An Independent Log M-E 
exists only in those systems that iiave access to mass storage. In 
Release 1, the Independent Log M-E functions are implemented by software 
components that reside in a C170 MDI and connected C170 mainframe. 

Each Dependent and Independent Log M-E belongs to one or more Log Groups, 
each of which is identified by a Log Group Number. Each Log Group 
contains a list of log messages included in it. This list is implemented 
as a bit map of all log messages included in the group. If a bit is set 
in the bit map, the corresponding log message is included in that Log 
Group. The Dependent Log M-E supports on-line commands to allow an 
operator to add or delete log messages in a Log Group. 
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3 4 4.1 Dependent Log M-E 

) .'cedent lo, M-E exists in e f h » j*- - £^£^3^^ O 

software components in that system for generation ana 



-\ 



messages 



As a part of system configuration ^Pendent log M-E is^i-a 11* * 
the Log Groups to which it belongs. This J^is a s combines each 

Sch of which identifies a log Group ^^^ou^to generate a Log 
such integer with the character string, Log ME_^ro^ ^ m _ £ ests a 

Group Title of the form "Log M-E Group "i- ^^"ofthelndependent Log 
JSfeS M -s^in S.ISSlS-'S -up should be sent. 

*. Dependent Log M-E -t-U^-.J.cjng^^ ^SJSSST* 

Log M-E in each Log Group. The **■£»£ £* ^ oup t0 the Dependent Log 
S! ^"SJSSS? lS?5£ lltstell^^n to transmit log messages to 
the independent Log M-E. 

The Dependent Log M-E ^^^^^^^SS^^ «"' 
which contains an entry for ea chj^ Grou p t o^h icn^ ^ ^ ^ to 

belongs. Each entry contains ^ bit map of tne og ^ ^ ^^ ^ 

that Log Group. Each entry also contains address^ > . fied as ^ one 

messages. V 

When the Dependent Log M-E receives a ^^^^^0^1^ 
message, it checks each Gorre^rdent^ta^Store entry transmit ted 

Group(s) that include that 2 t S^; i t?tt»TlStif!«i Log Groups, 
to the Independent Log M-E associated wiui 
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3.4.4.2 Independent log M-E 

The Independent Log M-E function is implemented by two software components. ^ 
One component, called the C170 Log Server, resides in the C17^ mainframe. The 
other component, called the Independent Log M-E, resides in the MDI connected 
to the C170 mainframe. These two components interface with each other via a 
C170 Network Products A-A connection. 

As a part of system configuration, the Independent Log M-E receives a list of 
Log Groups to which it belongs as well as the bit map for log messages in each 
Log Group. For each Log Group nj in this list, it registers the following 
Title in the Directory: 

"LOG M-E GROUP ni" 

The Independent Log M-E opens a Transport SAP and accepts connection requests 
from Dependent Log M-Es that belong to one or more of its Log groups. Once 
the connection is established, the Independent Log M-E transmits group bit 
maps to the Dependent Log M-E for the Log Groups belonging to that Dependent 
Log M-E. It receives log messages from the Dependent Log M-Es on the 
Transport connections and delivers the log messages to the C170 Log Server. 

The Independent Log M-E also provides an alarm service to the DCN network 
operators. The process used to provide the alarm service needs to be defined. 
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3 4 5 Piig access M-E 

IcSl system access to those files. 

^e File access M-E consists of two parts: ^ 

caEg^^ stora g e . 

pelease 1, only C170_ MDls ar e «pao ^ w . ^ ^ catenet 
configured with an IFA. At xecw 



must contain an IFA. 
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3.4.5.1 Dependent File Access M-E (DFA) J0 ^ 

The DFA provides two types of primitives to components in its local V ^ 
system: 

l 

file-specification primitives 

Open File 
Create File 
Delete File 

file-operation primitives 

Read File 
Write File 
Position File 
Close File 

During initialization or reconfiguration, an IFA registers a "file-type 
Si^-Si e £ch type of file that it supports. File-type Titles are used 
to control the location (s) within the DCN of particular types of files. 

When a file-specification primitive is issued, its parameters must 
include both a file-type Title and a file-name. For example, a component 
responsible for generating memory dumps as part of error processing would 
issue a Create File request to the DFA, supplying a file-type Title 

O indicating "dump file" service. Since a DFA has no direct access to g*\ 
secondary storage, it must locate an IFA that supports the requested \J 
file-type. The DFA uses the supplied file-type Title in a Translation y 
request and is returned a corresponding network address. 

The DFA then uses that IFA network address to establish a Transport 
connection with the IFA. The Transport connection is used by the DFA and 
IFA to exchange File Access Protocol Data units. 

Once the requesting software has been notified that the requested file 
has been opened or created, file-operation primitives can be used to 
manipulate the file. The Close File request causes termination of the 
Transport connection. 

The Delete File request causes both the establishment and termination of 
the Transport connection and hence is considered to be a 
file-specification primitive. 
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3.4.5.2 Independent File Access M-E (IFA) 

in Release 1, IFAs will reside only in C170 MDIs. Tne IFA does not 
access secondary storage directly, but instead cortmunicates over a C170 
SSSrtTSSSS connection to a File Server application on the C170 
host. The File Server application: 

receives file access requests from the IFA 

transforms them into NOS file access requests 

sends the results back to the IFA 

All file access requests/responses are multiplexed onto ^j*J™* IFA 
Products connection. This connection is initiated *V**IFh during IFA 
initialization and remains active during the life of the IFA. 

The following block diagram illustrates the software Processes and 
interfaces involved when an IFA is supporting two active file accesses 
from one DFA and one active file access from another DFA. 
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Each IFA in the network can be configured to support any subset of the 
Sported file-types. The configuration can be dynamically altered via 
cc^guration co^ands. The IFA registers a separate Title for every 
file-type supported. Each Title is associated with the IFA s network 
address. 
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3.4.6 Error M-E 

The Error M-E exists in all DIs to provide Internet and Internet users , 

with the ability to create Internet Error Reports (IERs) and send them to v_^ 
the originator of the message that caused the error. The Error M-E 
receives directives via intertask messages, usually from Internet, and 
sends IERs using Internet. The Error M-E can write IERs to log files. 

The Error M-E facility is provided via an intertask message interface. 
An error number, error parameter and 3B SAP ID of the entity detecting 
the error are specified along with the erroneous 3B PDU. 

An IER is created and sent to the message source, which is determined by 
examining the Internet header of the message in error. The IER is a 3B 
PDU, consisting of an error description field prefixed to the first 42 
bytes of the message in error. 

Certain IERs, listed below, are inappropriate to be returned to the 
message source; these are written to a log file instead. The Error M-E 
uses the Independent Log M-E (aka Log Support Application) to issue log 
requests under the following conditions: 

Checksum error - since the integrity of the Internet header is 
in doubt, the message source address may be incorrect. 

Multicast/broadcast - since one multicast may result in several 

data indications, IERs are not sent back to the source. _^ 

^"^ - IERs - since the Error M-E generates IERs, it makes no sense to VJ^ 

send IERs due to the receipt of bad IERs. 
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3.4.7 Echo M-E 



3.4. Tn¥orne >t. user to send a message 

^e Echo M-E provides the ability to : an Internet use^ ^ ^ M _ £ 

Z a particular system and ^f^^Trequest to send a 3B PDU to U 

services issues a normal Internet datagram jequ^ datagrain or 

the Echo 3B SAP in any DI in the <*****;; ^ by ^ e Echo M-E; fin 

Soao^ast^ulticast indications may ^P^eleSer. 

either case, datagrams will be returned to tn 

^e 3B PDU used for the Echo M-E is a normal 3B PDU with^an ^^ ^ 

^SSS^^JSS^JSA -option is a revest or a 

reply. 

• -* tria internet, to the message 
A 3B H=U received by the Echo M-E ^"^eS^equest." n»e 3B PDU 

^Ji££&SZ£2£Z* to W*" 

I£ *. echo-revest ^ssaoe is checKs^. the echo-reply —* «1 

also be checksummed. 

_j *.v,^ in pntte back to the message 
The Echo M-E uses Internet to send the 3B PDUs bacK 

source. 

3.4.8 initializa tion M-E 

t) - -s-iggffiK«S %^^£^ - loaJ C 

. js-rfentJni^aUHti^^ 

every bt's t^W« 
- Inaer^entJniU^tion^ - resides in the C170 a* in each 
Toaded/operationii MM 53 liT. 
tte £ure: tions of the initialisation M-E were descrihed previously as part 
of the DI load & startup process. 
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3.5 DCNS AND THE C170 

DCNS and the C170 together provide the following functions: 

support of C170 application-to-application (A-A) connections 
support of terminal-to-C170-application (T-A) connections 
network management via a C170 host console. 

access to CI 70 secondary storage files for loading, dumping, log 
information storage and other network management functions. 

ProdJcts COnSi ^ erati0nS ln thG design of the DCti int erface to C170 Network 

accommodation of future features such as C170/C1 80 A-A 
communications - C170/C180 A-A communication will, in future 
releases, be acconplished by terminating all Network Products 
logical links in the MDI. The Network Products Connection and 
Block Protocols are never carried across the DCN. C170 
application data traverses DCN as the data portion of DCN higher 
or middle layer protocol data units. Since the C180 supports 
the same protocols as DCN, C170/C180 A-A communication requires 
gmy only an agreement on application level protocols. jr< 

transparency of the interface to the C170 - The C170 MDI 
presents a local "255X NPU-like" interface to the C170. 
Physical and link protocols at the channel level are unique to 
DCN, but the Network Products Connection and Block Protocols 
have been preserved. 

The C170 MDI is configured in the Network Definition Language 
(NDL) as a local NPU. A C170 MDI is capable of supporting 
multiple logical links, but each logical link requires a 
separate CYBER channel and a separate MCI card in the MDI. 

provision f or support of all existing C170 networ king features - 
Existing C170 NetworK Products features are supported in the M DI 
by "NAM-level" software that is capable of processing the 
Network Products (NP) Connection and Block Protocols in support 
of A-A and T-A connections. The MDI contains a "gateway" 
function to interface DCN connections to NP connections. 
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^p Gateway Fu nction and HP Transforms 



X 



) *et-ay fu^ti* is provid^ ^sojt^ ^^f^ne?^ 
^l^nSTn^r^u^r^t^ understa^ both architectures 
^d at e a matber o£ both networks. < 

in this section. 

. w configured with an *•» V*?*f^ i ££2S.'3£? X^f 
CDNA and the architecture defined by OTT *»£• whlch is 

NDIs so configured P^'^SL^TxSs'So X™5. • 
described in the section entitleo ujmo <" 
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3.5.1 The Gateway Function and NP Transforms (continued) 

\J The gateway function in the C170 MDI is provided by software components V 

called "NP Transforms." NP Transforms interface C170 NP Connection/Block 
protocols to DCN Connection and Data Transfer protocols; thus/ no special 
software in the C170 is required to support these connection types across 
the DCN. The term "transform" is used in this document to mean a 
specific component that provides a gateway function; elsewhere, 
"transform" and "gateway" are used synonymously. 

An NP Transform is defined for each of the following connection types: 

A-A Transparent (Release 1) 

T-A Interactive (Release 1) 

T-A Batch (future release) 

Each NP Transform is a separate entity and each maintains an entry in the 
network Directory. Each NP Transform provides a unique service for 
accessing a specific C170 host in the DCN network. NP Transform names 
reflect the type of data traffic they support relative to the higher 
layer protocols involved in the transmission of the data. 

The A-A Transparent Transform deals with the transmission of A-A data 

O and does not require the services of any higher layer protocols; ^^ 

hence, the name "Transparent". | | 

The T-A Interactive Transform deals with the transmission of 
interactive data and requires the services of the ITS higher layer. 

The T-A Batch Transform deals with the transmission of batch data and 
requires the services of the BTS higher layer. This NP Transform 
will be provided in subsequent releases. 

NP Transforms cannot be used to select a specific C170 host application. 
C170 host application selection/switching is completely within the realm 
of the CI 70. 

Each NP Transform maintains one DCN connection/association for each 
active Network Products connection and must therefore be knowledgable in 
the connection management protocol of Network Products and one connection 
management protocol of DCN. 

The following diagram illustrates the relationship of the NP Transforms 
to other system components. 
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(<5 .1 The Gateway Function and NP Transforms (continued) 
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£LX^he!?norifies other network components of its availab ilityby 
registering itself with the Directory M-E, using the following fields. 

Tin. - the ASCII equivalent of the "host node" of the logical 
SnThetweenlne « host and M» ; NP Transforms in any given 
MDI all register the same Title. 

Network Address - the Network ID and System ID of the local 
system plus the 3B SAP ID as received in response to the open 
SAP request. 

"directl y accessible service" - identifies the NP Transform 
within an MDI by its underlying service. 
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3.5.1 The Gateway Function and NP Transforms (continued) 

The "directly accessible service" field serves two purposes: 

explicitly identifies the CDNA end-to-end protocols that are to 
be used when communicating with the associated NP Transform. 

implicitly identifies the unique function that the NP Transform 
performs. For example, a "directly accessible service" of ITS 
implies that the associated NP Transform supports T-A 
Interactive. 

The table below lists directory entries for a C170 MDI that supports all 
three possible Transforms. The host node number in this example is 
assumed to be "ID." 



C 



TRANSFORM NAME 


TITLE 


TRANSPORT SAP ADDRESS 


DIRECTLY 

ACCESSIBLE 

SERVICE 


T-A Interactive 


"ID" 


system-assigned 


ITS 


T-A Batch 


"ID" 


system-assigned 


BTS 


A-A Transparent 


"ID" 


system-assigned 


X.25 Support Layer 



4f'- 




Any network components wishing to communicate with an NP Transform must 
first obtain the network address from the Directory. For DCN release 1, 
an application may initiate contact with another application and a 
terminal may initiate contact with an application; therefore, the 
software entities that query the Directory are: 

Terminal Support Software in TDIs must determine the existence 
and network address ot T-A Transform (s) prior to establishing 
higher layer associations in support of terminal devices. 
Terminal Support Software is discussed in the section entitled 
"DCNS and Terminals." 

A-A Transparent Transforms must determine the existence and 
network address of other A-A Transparent Transforms prior to 
establishing connections in support of C170 A-A transfers across 

DCN. 
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3.5.2 C170 A-A Connections 

C170 A-A connections are supported via an X.25 Support Wr connection 
between gateway functions in two C170 MDIs, as illustrated below. 
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Each C170 host is interfaced to the DCN via a C170 MDI. An W connection 
exists between the gateway function in each MDI and its associated C170 
hoslf 2teSy functions communicate with each other using an X.25 
Support Layer connection. 

The C170 A-A connection can be initiated by either host. The C17CT MDI of 
lul «ni nn ho<?t selects the called host based on information in the 
^SS^S^S^Sl. Application selection is processed by the 
Network Validation Facility (NVF) in the called host. 

C170 applications refer NAM to a predefined OTTCALL block in orderto 
identify the host to be connected. The "dhost" field ^JheOMXLL 
olSk conSins the ASCII destination host node number. The "dhost field 
is included in the text portion of the A-A connection request service 
message sent from NAM to the MDI. 

The A-A Transparent Transform uses the "dhost" string as a Title for 
ojerying^^rectory for the network address of another A-A Transparent 
Transform that previously registered that Title with a "directly 
accessible service" of X.25 Support Layer. 
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3.5.2 C170 A-A Connections 

Because an A-A connection can be initiated in either host, the A-A 
Transparent Transform must be capable of processing connection 
indications initiated by either C170 Network Products or DCN. f Likewise, 
the Transform must be capable of making connection requests to either 
network. 

When connection processing is complete, the A-A Transparent Transform 
maintains two paired connections, both in the data transfer state. Data 
and control information arriving on either connection must be mapped into 
corresponding data and control information and sent on the paired 
connection. The A-A Transparent Transform is only involved in protocol 
conversion when processing data and qualified data. 

The Network Products Data Block Clarif ier (DBC) is removed from all data 
and qualified data received on the Network Products connection before the 
data or qualified data is sent on the DCN connection. Likewise, a DBC is 
constructed and prefixed to all data and qualified data received from DCN 
prior to sending to Network Products. The DBC removed/appended by the 
A-A Transparent Transform always has only the Transparent bit set. 

A connection termination message received on either connection causes the 
Transform to send a corresponding connection termination message on the 
paired connection. 
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353 ^nninal-to-cnO- Anolication (T-A) Connections 

ruScUon in the C170 MDI, as illustrated below. .. 
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processed by NVF in the C170 host. 

Si.ce the Network Pr^ucts design J£$X^J?&TS£& 

£^%3&&^w- *• « te ™ inology for these 

higher layer connections is "associations . 

<«► of * create Association indication, the T-A gateway function 
Upon receipt of a Creac f. ASS °r xcl ^" ^ ion Tike the a-A Transparent 
establishes a corresponding NP connects on.Uke the aa asso ^ ation and 

Transform ^^^^SS^iJ^^^^ * f^ 
connection, with "^ . T . ?J; n ~5 < T„ ^ connection and the T-A Batch 

between an ™ «^ a ^ i ^ a £^2 e S^S association and a PRU 
Transform maintaining a pairing Detween 

connection. 
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3 - 5 - 3 1terminal-to-C170-Application (T-A) Connections (continued) f~\ 



Oice the association/connection pairing is established, the T-A gateway 
function receives data and control information on an 
association/connection and sends corresponding data and control 
information on the paired association/connection. 

Unlike the A-A Transparent Transform which transmits transparent data, 
the T-A Transforms must provide mappings between dissimilar data 
presentation protocols. As such, their protocol conversion functions are 
somewhat more substantial. 

The T-A Interactive Transform does have a relatively simplistic mapping 
between IVT commands and ITS command services, because the initial ITS 
design is based on C170 IVT design with the mapping between the two a 
significant consideration. 

The conversion between IVT and ITS data units is more complex, involving 
IVT DBC creation based on ITS header and ITS header creation based on IVT 
DBC. 

The initial release of DCN, supports both edited terminal input and 
transparent terminal input. Physical representation of these two data 
formats are the same in both IVT and ITS data units. The initial 
implementation of the T-A Interactive Transform does not have to be 
concerned with any text processing functions that would be required in 
converting from one data format to another. 

T-A Batch Transform functions are not as yet completely defined. T-A 
Batch support is not a DCN Release 1 feature. 
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3.5.4 MDI-resident Software 

MDI-resident software within the C170 MDI serves two purposes: 

• n, a roa to applications and features in 
it allows user access, via the DCN, to appuca 

the C170 host. * 

it provides the » itself «itt '^^^TSSSL^S^ 
^^^oifio^eSo^nSiri^orat Peiease X «.. 

ft. prtory conponen, : of f e ««-££ softie %%£™£ 

MDI-NAM interacts with its users, as aepxL. 
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of MDI-NAM to coA nunicate with a <™jffggg & ^oveV^t^otk P roducts 
the C170 host. These ajplicat icnpair s« g ^ tQ provide 

defined for Release 1 are as follows: 
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3.5.4 MDI-resident Software (continued) 



FUNCTION PROVIDED 


MDI APPLICATION 


HELPER ^APPLICATION 


j File Access • ■ Independent File Access 
; •• Access M-E (IFA) 


I File Server 


.' Console Access I 


.' Independent Command M-E 
• & KDISP 


Operator Facility 


I Log Access I 


I Independent Log M-E j 


Log Server 



c 



^™iir*H«n» ST ;PPf icat i° n P ai " are implemented such that the MDI 
rSS "5 f ° f . the P 3 " is Physically contained partially or 
fSSte S£S a ?h lndepend f t management-entity rathS than existing as 
SrSSI » n»dule; the concept of MDI "application" is retained simply to 
provide a mental model of the functionality and to maintain consistency 
with existing overview documentation of the system. consistency 



appears later in this section 



Additional information on MDI "applications' 
and in the section on "Network Management." 

£Sare^ liCati ° nS "" described in the se< =tion on "CI 70 -Resident 

The NP gateway function uses MDI-NAM to map Network Products protocol to 
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3.5.4.1 MDI-NAM 

^e C170 Network Products (NP)^ Bloc * ProtaaA ^ne^the concept^ ^ 

"logical links" **?«£™*g™ \l "£%£ u^he physical link 
between a host and frontend 255X NPU ^^ s link ^ ontai ns up to 256 
consisting of a CYBER channel. Each logical iin chann nel. The 

logical connections, one of ^ lch } s ^^JI% Establish and 
s«vice channel is used to c °T a r^2 u ?STSl iSgfcailink; the other 
terminate other connections «£*"££ ^tween^unicating 
255 connections are used to transmit data between 

applications. 

«* presents virtually the sa*e interne to gjOTOtaJt- does 

«» „ Bloc, Protocol interface^o,- ^ - *£^»!"£. 
use the MP Block Protocol to d*™™;?"* "fthat used by the OCP SVM; no 
I^Kfsort^s r^Jrel S^errace^ the .& «-« BXP. 

MDI-NBMdoes, however,, use a ^J ™^ 3 "?^™^!^^!^ (FCI 
ST- « SSSS.-tJTSSTS S SfeS-^version or the 2S5X PXP 
in the C170 PPU. 
„ BXP depends r ^-Srcoupler^^h^^nni^r 1 

S^a^r^tlon? £ SSS if illustrated in the ri 9 ure 
belo" . Mrvr-NflM STRUCTURE 
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3.5.4.1 MDI-NAM (continued) 

Services provided by SVM include: 

Logical c onnection management - accomplished through SVM's 
interfaces to BIP and to its "users." "Users" call SVM ik> establish 
and terminate connections with NAM; SVM then calls BIP to send the 
necessary service messages and protocol elements to NAM. Messaqes 
from NAM are passed to SVM by BIP. 

logical link status m aintenance - MCI-SSR will inform SVM of a 
change in the status of the logical link by building a service 
message and routing it through BIP to SVM. SVM will change the 
status of the logical Link Control Block for that logical link. 

BIP communicates with NAM in the C170 host via the NP Block Protocol to 
provide data transfer services across an established Network Products 
connection. BIP additionally supports a local interface with SVM for 
the exchange of connection management messages between SVM and NAM. 

All messages from the C170 to the MDI arrive at BIP from the MCI-SSR. 
Connection management and logical link status messages are delivered to 
SVM for processing. All other messages are delivered to the appropriate 

All messages from the MDI to the C170 leave BIP through the MCI-SSR 
Such messages may originate either from SVM in the case of connection 
management messages or from a "user." 
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3 5.4.2 MDI "Applications" 
3 m plication" is a ^J^™*™ ^"SlXeS S^ 

nvanagement-entity. 

MDI "applications" reside within a C170 ^1 and co^unicate with peer 

helper applications in the C170 ^* ™ /Lj^t^J^ peers support 
connection. MDI "applications" and ^eir C170 hostheiper pe «~ 
three network management functions, for which the DCN is depena 
external sources. 

File Access 

Access to C170 files is provided by the Independent File ««»(DN 
access w^'» * described in the section entitled File 

^Sondary storage for all DCN files except log files. 
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3.5.4.2 MDI "Applications" (continued) 
f^ Console Access /"">, 

The NAM K-Display at the C170 console is used to manage the DCN. DCN 
commands are entered and command responses are received by the 
operator at the NAM K-Display. 

Access to the NAM K-display, is provided by two modules resident in 
the MDI: 

the K-display Supervisor (KDISP) 

the Independent Command M-E 

For purposes of discussion within this section of the ERS, these two 
modules will be considered jointly to be the MDI "application" for 
console access, as illustrated below, (it might be noted here that, 
in other DCN documentation, the Independent Command M-E is 
occasionally called the "Operator Support Application (OSA) " in 
recognition of its dual role as both a management-entity and an MDI 
"application.") 

KDISP establishes and supports a Network Products A-A connection, 
using SVM, to communicate with the C170 Operator Facility helper 
application. During initialization, KDISP initiates an A-A 
connection request, supplying INCALL application name information to 
identify the Operator Facility as the requested helper application. 
The Operator Facility is started by NAM and the connection is brought 
to a fully operational data transfer state. KDISP will reinitialize 
the connection if it detects an A-A protocol error or if it receives 
notification of an unsolicited TCN/AP/R connection termination. 

The Independent Command M-E (aka Operator Support Application) in the 
MDI uses KDISP to transmit command traffic between the network and 
the C170 console, as described in the section entitled, "Command M-E." 
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3.5.4.2 MDI "Applications" (continued) 
Console Access (continued) 
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3.5.4.2 MDI "Applications" (continued) 



Log Access 



Access to C170 secondary storage for log information is provided by 
the MDI-resident Independent Log M-E; a description of the 
Independent Log M-E may be found in the section entitled "Log M-E " 
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355 ci70-resident Software 

functions: 

- builds load and configuration files for the DCN 

. loads a C170 MDI as the first step in loading the network 

- provides network managenent function support via C170 helper 
applications 

analyzes DCN network performance 
analyzes DI dumps 

3.5.5.1 Load and Configuration Files 
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3.5.5.2 MDI Loading 

INITMDI is the C170 software responsible for the initialization of /"> 

channel-connected C170 MDIs. INITMDI functions as an independent V-> 

Initialization M-E and is comprised of a C170 CP program and a PP 
helper. The CP program is activated as the result of an initialization 
request from the MDI. The CP program is responsible for executing the 
Initialization protocol with the MPB ROM bootstrap of the requesting 
*Ph . ?? e C ? P r °gram requests the PP program for sending and receiving 
initialization protocol data units. 

INITMDI uses the NOS EST interlock to lock out all other C170 processes 

from trying to use the loading MDI. Once the entire load file is 

transferred to the MDI, the EST interlock is cleared and the EST for the 

MDI enters an operational state. The operational state is noted by NAM 

and a PIP is assigned to the MDI. Error and status information pertinent 

*° ^^i^ 00 are re P° rted to the operator by an INITMDI interface to 
the NAM K-Display. 
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3.5.5.3 C170 Helper Applications 

The Operat or Facility maintains an A-A connection with the MDI (f\ 

"application," KDISP. Together, these two provide the capability of KJ 

managing the DCN from the NAM K-Display. . 

The Operator Facility is initialized when NAM receives an A-A incall from 
the KDISP MDI "application." AOF validates the connection by requiring 
that a specif ic text message be received from the calling application as 
the first data unit after the connection is established. After 
validation, the connection can be used to send DCN commands and receive 
DCN command responses. The operator uses standard NAM K-Display 
procedures for interfacing to the Operator Facility. 

The File Serve r Facility in the C170, along with the independent File 
Access M-E in the MDI, p rovides secondary storage access capabilities for 
DCN The File Server is capable of providing multiple simultaneous file 
accesses to the same or different NOS-resident files. All file accesses 
are multiplexed across one A-A connection. File uniqueness " 
accomplished by assignment of a file identifier (FID) to each active 
file. Tne FID is assigned by the independent File^ Access M-E when the 
file is opened. The FID remains associated with the file until the file 
is closed. 

The File Server supports the file functions of open, create, delete, 
read, write, position, and close. 

NOS-resident files are used by DCN to support the network J^«f* r 
functions of DI loading, DI configuration, DI dumping, and network user 
validation. 

The Log Server and the independent log M-E in the MDI P^^ a network 
logging and ala rm capability. Tne log Server receives log messages from 
the independent Log M-E and writes them to a formatted log file. 

The Log Server examines each log message to determine if it is also 
currently selected as a network alarm. In addition to being written to 
the DCN log file, alarm messages are displayed. The mechanisms for 
processing alarms are currently being defined. 
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3.5.5.4 Network Performance Analysis 

The Network Performance Analyzer (NPA) is both a batch report generator 
and interactive processor of the DCN log file. Network management 
personnel use NPA to gather and analyze the performance aspects of the 
DCN. NPA generates reports to highlight trends that aid in early 
detection of imminent hardware failure, present and future configuration 
requirments, and network capacity, bottlenecks, and throughput. 






3.5.5.5 DI Dump Analyzer 

(♦♦♦♦TO be SUPPLIED****) 
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3.6 DCNS AND X.25 

mis m*y be configured to Interface ^^j^S ^sform 

sssr t^reTc-an ?,£?££--£ 

» e X.25 gateway is unlike the KP gateway in that It*- £ ™ 
multiple specialized components. The X.25 gateway onxj «~ 
Transparent connections. 

tt e diagram below illustrates the relationship of the X.25 Transform to 
other system components. 
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StSrion'rSress? ^S^licS selection is 
accomplished at the destination host. 
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3.6 DCNS AND X.25 (continued) 

|J When CI 70 applications initiate an A-A connection that traverses both DCN 
f nd transparent X.25, the C170 COTCALL block is configured with a "port" 

£2?J??%S 8 iS PP ! hle to „ the . Title of the X.25 Transform providing the 
2?S J interface. Mapping of this parameter into the appropriate 
Title and searching of the directory will be performed by theliP gateway 
function in the MDI associated with the calling host. 

The NP A-A Transparent Transform will obtain the "port" field from the 
text portion of an ICN/AP/R service message. If the value of the "port" 
tield is zero, the requested connection is not to traverse a transparent 
i ..i n „ ace; ln t^ 55 case ' the ^ A " A Transparent Transform will use 

S^K?°2;\ f i e i? Wlthin the IGN /APA text as a Title for locating 
another NP A-A Transparent Transform. * 

When the X.25 gateway receives an incoming call indication, the eighth 
and ninth octets of the call user data are used as a Title for locatinq 
the NP A-A Transparent Transform that services the requested host. By 

S^Xt? 03 ^, 001 ^* 1011 ' these tMO octets of call user data contain 
the ASCII equivalent of a C170 host node number; this convention will be 
used m the initial release of DCN so as not to affect the existinq 
Network Products design in this area. 

Because the external design of the X.25 Support Layer is almost identical 
to the external design defined by DCN for the X.25 Packet Level, the 

O mapping of connection and data transfer protocols between the two "~ \ 

entities is a relatively straightforward process. The X.25 Transform fl 
maintains connection pairings just as the NP gateway function does. The ^-^ 
connection pair consists of an X.25 Support Layer connection and an X.25 
virtual circuit. The X.25 Transform receives service indications on a 
connection/virtual circuit and issues the corresponding service request 
on the paired connection/virtual circuit. ^ 

2 S^k 1 ™ 1 ^ r ?i SaS ! °^ DQI ' an X * 25 interface is available in support 
of both DCN itself and also in support of C170 A-A connections that 
traverse an intermediate X.25 virtual circuit link. 

DCN utilizes X.25 virtual circuits as CDNA network solutions, 
connecting two NDIs via a public data network (PDN) . The virtual 
circuits carry DCN Internet datagrams, complete with all CDNA 
protocols. 

When X.25 virtual circuits are used as intermediate links in a C170 
A-A connection, data units appearing on the virtual circuits are free 
of any CDNA protocols. Since only the application's data units 
themselves are present on the virtual circuit, the virtual circuit is 
commonly called a Transparent X.25 virtual circuit. 
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3.6 DCNS AND X.25 (continued) 

1) The diagram below illustrates use of X.25 virtual circuits as CDNA Q 

* network solutions, R>ur NDIs are pictured, each with an X.25 interface \Jf 



to a common PDN. 
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^S Assuming the configuration is fully connected, each NDI pictured above 
V J maintains one Ethernet network solution and three X.25 virtual circuits v j 

S point-to-point network solutions; e.g., NDI "A" uses one virtual 
circuit to communicate with NDI "B", the second to communicate with NDI 
"C". and the third to communicate with NDI "D". These virtual circuits 
are used by Internet entities within the NDIs for sending and receiving 
Internet datagrams. 
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3.6 DCNS AND X.25 (continued) 

The diagram below illustrates use of an X.25 virtual circuit as an 
intermediate link in a CI 70 A-A connection. A Transparent X.25 virtual 
circuit is always used by DCN when communicating over an X.25 interface 
with "foreign" systems; i.e., systems that do not implement the DCN 
protocols. 
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C170 host "A" is connected to an NDI that interfaces to X.25; C170 host 
"B" is connected to a front-end 255X that interfaces to X.25. Ihe C170 
A-A connection in the diagram is really comprised of four distinct 
intermediate connections joined together by gateway functions: 



ENTITIES CONNECTED 
C170 host/ MDI 
MDI / NDI 
NDI / 255X 
255X / C170 host 



INTEFMEDIATE CONNECTION TYPE 
NP connection 

X.25 Support layer connection 
Transparent X.25 virtual circuit 
NP connection 



o 



Gateway functions exists in the MDI, NDI and the 255X. Since the 255X 
does not implement the DCN protocols, the NDI and 255X "gateway" 
communicate over a Transparent X.25 virtual circuit. Only the 
application's data units, or a portion thereof, appear in the packets 
that traverse the X.25 virtual circuit. 
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3.7 DCNS AND TERMINALS 

Within the TDI, 



OCN tergal su*»rt is inclement** ^,™ "^^-Sk ?! £" ' 
unique Terminal Interface .^^ Jf tne^Sde range^f available terminal 
'">. various P**^**^^' °beSeen terminll types, many of the Q 

*J types. Despite dissimilarities «*ween w advantage of this * *> 

factions that TIPS perform are e«n. J^^ sirnplif ied TIP design, 

ss^ass T^rtfon^ryj^s ^ «u- -—m**** 



Software. 



^inal users su*>ly «^KSSST ^h^selS? ^ 
select information ^ring initial ^erchang ^^ iva i ent of 

information is used to construct a Tiue^ querying the network 
S^rylol "^Trans^t S^adcreSt, ° ^T-A Transform*, 
servicing the selected host. 

- The Transport SAP a*ress of *£J«f-*&K ^^ 
SSSSiTS'S^t- S."S£Sx'. inter^tive device,*,. 

- The Transport SAP stress «J*™g~32*S ^directly 
'££%£%%£& Sinai's hatch device.s,. 

Terminal Support Software is inplemented in t~ major modules: 

the Line Control Module (UM) 

- the Terminal Data Services Modules (TOSM, . 

A TIP interfaces to in ■-«£Sl*?£ 1 S££u52' SToS»l 
created and deleted unSer the ^"^"Lir^. At the highest level, 
blocks are organised in a hierarchical fashion ^ tion and 

SnS^ice^tKagSfoS-n is used t, hoth the 
TIPS and the Terminal Support Software. 
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